@igorcamilo We are hiring 100% remote positions that are mostly java focused (but expecting polyglots).. not sure youll be a great fit (no iOS) but I saw "Java" and thought id let you know. Im the owner and hiring manager. Here are the positions we have:
If you asked how @SwiftStudio going. Well... it been better. Apple #Swift just recently decided to shutdown #SwiftPM API I use (to make things CLI cannot provide). I find it unexpected (to me, not to apple) move after many years. https://github.com/apple/swift-package-manager/issues/7440
I'm disappointed with a move in that direction and find that decision harmful for the third-party dev tooling ecosystem trying to adopt SwiftPM. IMHO.
We are going to draw inspiration for the @vuejs ecosystem to design @tuist ’s
approach to open source. We’ll extract reusable functionality into independent layers as Swift Packages for anyone to use, and come up with new layers to underpin some future Tuist Cloud ideas.
Besides XcodeProj, which we open sourced a long time ago, we’ll extract Tuist’s generation logic into an XcodeProjectGenerator package, and we are also working on SwiftTerminal, a set of tools to build better CLIs in #Swift
This weekend I was frustrated with my debugging, and just not up to digging in and carefully, meticulously analyzing what was happening. So … I took a left turn (at Alburquerque) and decided to explore an older idea to see if it was interesting and/or useful. My challenging debugging was all about network code, for a collaborative, peer to peer sharing thing; more about that effort some other time.
A bit of back story
A number of years ago when I was working with a solar energy manufacturer, I was living and breathing events, APIs, and running very distributed, sometimes over crap network connections, systems. One of the experiments I did (that worked out extremely well) was to enable distributed tracing across the all the software components, collecting and analyzing traces to support integration testing. Distributed tracing, and the now-popular CNCF OpenTelemetry project weren’t a big thing, but they were around – kind of getting started. The folks (Yuri Shkuro, at least) at Uber had released Jaeger, an open-source trace collector with web-based visualization, which was enough to get started. I wrote about that work back in 2019 (that post still gets some recurring traffic from search engines, although it’s pretty dated now and not entirely useful).
We spun up our services, enabled tracing, and ran integration tests on the whole system. After which, we had the traces available for visual review. It was useful enough that we ended up evolving it so that a single developer could stand up most of their pieces locally (with a sufficiently beefy machine), and capture and view the traces locally. That provided a great feedback loop as they could see performance and flows in the system while they were developing fixes, updates and features. I wanted to see, this time with an iOS/macOS focused library, how far I could get trying to replicate that idea (time boxed to the weekend).
The Experiment!
I’ve been loosely following the server-side swift distributed tracing efforts since it started, and it looked pretty clear that I could use it directly. Moritz Lang publishes swift-otel, which is a Swift native, concurrency supported library. With his examples, it was super quick to hack into my test setup. The library is set up to run with service-lifecycle pieces over SwiftNIO, so there’s a pile of dependencies that come in with it. To add to my library, I’d be a little hesitant, but an integration test thing, I’m totally good with that. There were some quirks to using it with XCTest, most of which I hacked around by shoving the tracer setup into a global actor and exposing an idempotent bootstrap call. With that in place, I added explicit traces into my tests, and then started adding more and more, including into my library, and could see the results in a locally running instance of Jaeger (running Jaeger using Docker).
Some Results
The following image is an overview of the traces generated by a single test (testCreate):
https://josephheck.files.wordpress.com/2024/04/trace_overview.pngThe code I’m working with is all pushing events over web sockets, so inside of the individual spans (which are async closures in my test) I’ve dropped in some span events, one of which is shown in detail below:
https://josephheck.files.wordpress.com/2024/04/trace_with_detail.pngIn a lot of respects, this is akin to dropping in os_signposts that you might view in Instruments, but it’s external to Xcode infrastructure. Don’t get me wrong, I love Instruments and what it does – it’s been amazing and really the gold standard in tooling for me for years – but I was curious how far this approach would get me.
Choices and Challenges
Using something like this in production – with live-running iOS or macOS apps – would be another great end-to-end scenario. More so if the infrastructure your app was working from also used tracing. There’s a separate tracing project at CNCF – OpenTelemetry Swift – that looks oriented towards doing just that. I seriously considered using it, but I didn’t see a way to use that package to instrument my library and not bring in the whole pile of dependencies. With the swift-distributed-tracing library, it’s an easy (and small) dependency add – and you only need to take the hit of the extra dependencies when you want to use the tracing.
And I’ll just “casually” mention that if you pair this with server-side swift efforts, the Hummingbird project has support for distributed tracing currently built in. I expect Vapor support isn’t too far off, and it’s a continued focus to add more distributed tracing support for a number of prevalent server-side swift libraries over this coming summer.
See for Yourself (under construction/YMMV/etc)
I’ve tossed up my hack-job of a wrapper for tracing during testing with iOS and macOS – DistributedTracer, if you want to experiment with this kind of thing yourself. Feel free to use it, although if you’re amazed with the results – ALL credit should go to Moritz, the contributors to his package and the contributors to swift-distributed-tracing, since they did the heavy lifting. The swift-otel library itself is undergoing some major API surface changes – so if you go looking, I worked from the current main branch rather than the latest release. Moritz shared with me that while the API was not completely solid yet, this is more of the pattern he wants to expose for an upcoming 1.0 release.
Onward from here
I might push the DistributedTracer package further in the future. I think there’s real potential there, but it is not without pitfalls. Some of the challenges stem from constantly exporting data from an iOS app, so there’s a privacy (and privacy manifest) bit that needs to be seriously considered. There are also challenges with collecting enough data (but not too much), related choices in sampling so that it aligns with traces generated from infrastructure, as well as how to reliably transfer it from device to an endpoint. Nothing that can’t be overcome, but it’s not a small amount of work either.
Weekend hacking complete, I’m calling this a successful experiment. Okay, now back to actually debugging my library…
#iOSDev What's the proper way of handling Required Reason APIs when the API in question is only referenced by a part of a #swift package dependency that I'm not ever calling?
None of the usage reasons fit – there's no way to declare “this is only linked because a dependency references it, but I pinky promise my app doesn’t actually call it”
@dale_price I'd work with the package maintainer to make that part of the package optional. In the short term, I'd consider forking, removing the problematic code, and using my fork until the changes can be upstreamed.
Today begins a long journey towards learning #swift. For the beginning of my journey, after reading a few articles at @twostraws, I chose to create a REST API with the @codevapor framework.
Announcing swift-fakes, the beginning of standardized test doubles for Swift!
Swift Fakes aims to provide standardized implementations of common test doubles, massively improving the readability and reliability of your tests. Currently, Swift Fakes provides the Spy class, for recording calls and returning stubbed responses. But I'm aiming to expand its offerings quickly.
I’m having a hell of a time with AVAudioSession, trying to get both AVSpeechSynthesizer and AVAudioRecorder working in the same app (not at the same time). Anybody done something like this? #Swift#iOS#iOSDev
@brandonhorst We usually find it’s best to stick with .playAndRecord and avoid switching between categories else the number of possible audio lifecycle states really blows up. Are you getting the recorder and synth working but not as desired, or not working at all?
@NameItGames Thanks! I think I got something working, by keeping .playAndRecord enabled all the time (like you said) and also setting usesApplicationAudioSession = false on the AVSpeechSynthesizer. I haven’t tested all the edge cases yet, but at least nothing just stops working as far as I can tell.
On my journey to convert SwiftyJSON in Cork to Codable, I ran into a slight problem. Some of the JSON I’m parsing has this format:
[{formula: { // the data that I actually need}}, cask: { // empty and I don’t care}]
Is there a way to access the data inside “formula”, without having to define Formula as a useless struct? Using SwiftyJSON for this made the code really nice, since I could directly access the data in there.
@davidbures@melgu@codedbydan That looks like what I ran into with the "id" property expected to be in the JSON data. I got around that by making my "id" property a computed property. JSONDecoder/JSONEncoder ignore those. I don't know if that would work for you in this case.
@puppethead@melgu@codedbydan Interesting idea, but it unfortunately doesn't work in my case. Making it a computed property makes my navigation stop working.
At times like this, I wish there was something like a @noncodable property wrapper that would allow you to exclude a property from the encoding/decoding process, instead of having to duplicate everything in CodingKeys :x
huh, this is really cool: there's a GNOME library for Swift that provides a declarative SwiftUI-style method for writing the UI views https://www.swift.org/blog/adwaita-swift/
in fact, the simple examples they used look almost exactly like SwiftUI, lol
