Let’s say you’ve got a suite of XCUITests that takes 90 minutes to run. And let’s say you run those tests in a CI, such as Bitrise. And let’s say those tests start failing fairly early on in the run, many of them, if not all of them!

Quite possibly the logs you see in CI aren’t necessarily going to have all the information you need to figure out why the tests are failing. In this case what you need is the .xcresult that will only become available once the tests have completed. And certainly with Bitrise you can’t end the pipeline early, otherwise you’ll never get that .xcresult. But it could be a long wait, up to 90 minutes, or even longer if your tests tend to take longer when they’re timing out.

If something as terrible as this has happened in your tests there’s likely zero value in running the remaining tests. There’s clearly something fundamentally wrong with this test run that will be apparent from the failures so far and will likely be the same for all remaining tests. So why not just skip all the remaining tests?

This was the situation I found myself in for the nth time and figured I’d spend some of those wasted minutes looking for a solution.

I came across XCTestObservation, a protocol that can be used to be informed of tests going through their lifecycle, such as starting, recording issues and finishing.

I put together a simple implementation of this and it works nicely!

You can then put it into use in your XCUITests like so:

Initially the recorded failure count will be zero so shouldSkipAllTests will report false and not skip each test being run. If enough tests fail then it will become true and all tests from that point will be skipped, bringing your test run to a much quicker end.

Some things to consider:

• If your tests are setup to retry when they fail then each failure will add to the failure count, which may or may not be desirable. One way to solve this might be to count unique test failures rather than just adding one on every failure.
• Consider whether the total number of failures is right for your use case. Perhaps you’d rather count the number of failures in a row than just the total number across the whole test run.
• I used a singleton for simplicity, you might prefer/need something a little different
• If your tests run in parallel you’ll need to make sure TestObserver is thread-safe to avoid problems.

If you’re a dev and you run tests in CI then you’ve probably run into the scenario (many times) where the tests are fine on your machine but on CI they fail.

And many times you just can’t tell what’s going wrong from the UI test results or the test runner’s logs, you can just tell that something is going wrong under the hood in the app and if you could see the logs of the app the answer would likely be apparent.

But where are those logs? They’re not available on CI, you just see the test runner’s logs, something like this:

2024-04-25 18:50:44.436099+0100 TestAppUITests-Runner[21640:5238984] [Default] Running tests...
    t =      nans Interface orientation changed to Portrait
Test Suite 'TestAppUITests' started at 2024-04-25 18:50:53.439.
Test Case '-[TestAppUITests.TestAppUITests testExample]' started.
    t =     0.00s Start Test at 2024-04-25 18:50:53.441
    t =     1.07s Set Up
    t =     1.16s Open com.chrismash.TestApp
    t =     1.16s     Launch com.chrismash.TestApp
    t =     5.69s         Setting up automation session
    t =    10.12s         Wait for com.chrismash.TestApp to idle
    t =    13.30s Waiting 5.0s for "Hello, world!" StaticText to exist
    t =    14.33s     Checking `Expect predicate `exists == 1` for object "Hello, world!" StaticText`
    t =    14.34s         Checking existence of `"Hello, world!" StaticText`
    t =    14.71s Tear Down
Test Case '-[TestAppUITests.TestAppUITests testExample]' passed (15.088 seconds).
Test Suite 'TestAppUITests' passed at 2024-04-25 18:51:08.529.
  Executed 1 test, with 0 failures (0 unexpected) in 15.088 (15.090) seconds

I’d been plagued by this for years and hadn’t found a solution to it. I think fastlane might have options to get at the app logs, but that wasn’t a great option for some of the projects I was working on.

Then I stumbled on an answer on StackOverflow that had appeared only a couple of months ago, pointing out that you can use the xcresulttool that ships with Xcode to extract the logs from an xcresult file!

The process outlined is a bit tedious to do repeatedly but, as henrique pointed out, it’s totally scriptable and I love nothing more than scripting tedious tasks, so I had to give it a go.

I’ve shared the resulting script here: https://github.com/ChrisMash/XCResultExtractor. It’ll output something a little like this:

Standard output and standard error from com.chrismash.TestApp with process ID 21774 beginning at 2024-04-25 17:50:58 +0000

App initialised
ContentView initialised
2024-04-25 18:51:03.553575+0100 TestApp[21774:5241363] [Default] Received request to exchange capabilities, remote interface capabilities are: <XCTCapabilities: 0x600000004840>: {
    "query runtime issue reporting" = 1;
    "query runtime issue reporting/automation type mismatch" = 1;
}
2024-04-25 18:51:03.561337+0100 TestApp[21774:5241363] [Default] Received request to notify when the main run loop is idle
2024-04-25 18:51:03.561388+0100 TestApp[21774:5241363] [Default] Idle notifier finished setting up run loop observer
2024-04-25 18:51:03.561542+0100 TestApp[21774:5241363] [Default] Received request to notify when animations are idle
2024-04-25 18:51:03.561583+0100 TestApp[21774:5241363] [Default] Sending animations idle reply with error: (null)
ContentView: @self changed.

There’s “noise” in there from the interaction between the test runner and the app (requests for view hierarchies etc.), but it’s definitely better than nothing. You can see the three logs that the test app (included in the repo) outputs:

App initialised
ContentView initialised
ContentView: @self changed.

It’s already helped me out a ton already so I’m looking forward to the future chances to make use of it, rather than dreading them!

As I predicted in my last blog, Preparing for Swift 6, it seems Swift 6 is actually heading for a September release date!

The Swift forums post on the Swift 6 Release Process has announced that the Swift 6 release branch is being created March 15th. Given Swift 5.10 is going out in Xcode 15.3 in March it tallies up with the release history of Swift that 6.0 will release in September and be included in Xcode 16. Though we’ll have to wait for WWDC for confirmation on that, I’d be very surprised if it happened any differently!

So maybe it’s time to start enabling all those Swift-6-preparatory feature flags in your projects so the adoption of Swift 6 goes as smoothly as possible! Read more in my last blog: Preparing for Swift 6

First things first. Let’s address that bizarre image… I used Bing’s AI image creator to try and show a number 6 fighting a number 5, to represent the breaking changes Swift 6 is bringing. But it seems the AI struggled with that and decided to give me this unholy abomination instead, which I feel deserves to be shared as far and wide as possible!

When is it coming?

Swift 6 will bring numerous breaking changes to iOS, which is something Apple have been preparing for quite some time. They’ve been implementing breaking changes in Swift 5, hidden behind feature flags, which will become the default behaviour in Swift 6.

It’s been under discussion since at least January 2020 but there’s actually still no announcement on when it will be released.

The following are some key posts from the Swift forums relating to Swift 6:

January 2020: On the road to Swift 6
January 2023: Design Priorities for the Swift 6 Language Mode
November 2023: Progress toward the Swift 6 language mode

Swift has been consistent with a cadence of March and September for major/minor releases. September 2023 saw 5.9 released and 5.10 has already been mentioned, which will presumably come along in March 2024.

Perhaps Swift 6 could come along in September 2024? Maybe we’ll see it announced at WWDC, giving us a few months to get fully prepared? Though that’s a wild guess really, more years might roll by before we see it released!

What do we need to do?

To get your code ready for Swift 6 you can start enabling the various feature flags Apple have provided in Swift 5 and fixing the warnings or errors produced.

Ensure you enable the feature flags on all targets: framework, app, unit/UI tests etc. And also make sure you clean the targets and build/run them (test targets often don’t actually build until you run them) to get Xcode to report any warnings or errors.

Inspect and clean up anything it reports and you’ll be in a much better place to adopt Swift 6 when it’s finally released! If possible you should keep the feature flags enabled so that any new code you write before Swift 6 comes along will be written compatible first time!

If necessary you can check if the -enable-experimental-feature flags are enabled or not in your code with hasFeature (read more here). Even when Swift 6 is adopted hasFeature will report true so you don’t have to worry about it thinking the feature flags don’t exist anymore! In some situations this might help to prepare code early if it requires any kind of incompatible change as you can have both old and new code present at the same time.

Things we can opt into early

Progress toward the Swift 6 language mode calls out various things we can already opt into voluntarily.

I’ve summarised everything I could find here for you and provided a bit of a summary and high level assessment. Bear in mind that I’ve not fully digested everything I’m linking too and not played around with many of these feature flags so take it all with a pinch of salt!

SE-0274: Concise magic file names

Summary: #file will evaluate to <module name>/<filename> rather than a full file path. #filePath is introduced if the full file path is still required

Compiler flag: -enable-experimental-feature ConciseMagicFile or -Xfrontend -enable-experimental-concise-pound-file

The latter is mentioned as a prototype (not exactly the same as the final intention). It’s unclear whether that applies to the experimental feature flag too or not.

High level assessment: Seems unlikely to cause issues for most projects unless there’s anything very specific about any #file usage

SE-0286: Forward-scan matching for trailing closures

Summary: Trailing closure matching scans backwards through parameters to find a match but will instead scan forwards, which may cause changes in behaviour if a function has multiple closure parameters (with default values) of the same type and the trailing closure syntax is used.

Compiler flag: -enable-experimental-feature ForwardTrailingClosures

High level assessment: Currently not clear what the decision for Swift 6+ is going to be, so hard to assess the impact as there may be none. It may be worth assessing risky usage of trailing closures and updating to be explicit.

SE-0337: Incremental migration to concurrency checking

Summary: Swift 5.5 introduced the Sendable protocol to help eliminate data races, though it was not enforced, in 6 it will be

Build setting: Strict Concurrency Checking
Compiler flag: -enable-upcoming-feature StrictConcurrency or -warn-concurrency

High level assessment: This is one of the biggest impacts. Properly conforming to Sendable isn’t always straight forward and you don’t need to be using async/await for there to be errors! A project I work on had 600+ errors when enabling complete concurrency checking. There’s some useful additional reading on SwiftLee.

SE-0352: Implicitly Opened Existentials

Summary: Improvements to existentials to make them easier to convert back into generics, removing some compiler errors that could currently be encountered

Compiler flag: -enable-upcoming-feature ImplicitOpenExistentials

High level assessment: For the most part seems like it likely won’t have any effect, but it’s possible that a different overloaded function might end up getting picked with the new behaviour

SE-0354: Regex Literals

Summary: New support for defining regex literals with /…/ will be enabled in Swift 6, which could clash with some comment blocks etc.

Build setting: Enable Bare Slash Regex Literals
Compiler flag: -enable-upcoming-feature BareSlashRegexLiterals

High level assessment: Should be simple enough to enable ahead of time and see if anything breaks, modifications should be straight forward

SE-0383: Deprecate @UIApplicationMain and @NSApplicationMain

Summary: Use of UIApplicationMain becomes an error in Swift 6 (already meant to be a warning in Swift 5, though it’s not coming up as one for me!)

Compiler flag: -enable-upcoming-feature DeprecateApplicationMain

High level assessment: Trivial to replace it with @main

SE-0384: Importing Forward Declared Objective-C Interfaces and Protocols

Summary: Improve usage of ObjC libraries from Swift code around forward declarations

Compiler flag: -enable-upcoming-feature ImportObjcForwardDeclarations

High level assessment: Unlikely to be an issue for most, just a benefit. Currently workarounds would be in place to make the ObjC code usable from Swift and these could be removed from Swift 6, potentially speeding up build times a little.

SE-0401: Remove Actor Isolation Inference caused by Property Wrappers

Summary: Property wrappers currently infer actor isolation, which can be confusing, they won’t in Swift 6

Compiler flag: -enable-upcoming-feature DisableOutwardActorInference

High level assessment: Any use of property wrappers might cause a change in actor isolation in related code, which could cause compilation errors that need resolving.

SE-0409: Access-level modifiers on import declarations

Summary: Ability to keep dependencies internal to a module

Compiler flag: -enable-experimental-feature AccessLevelOnImport
or maybe -enable-experimental-feature InternalImportsByDefault

High level assessment: Shouldn’t be too much impact. Imports will be internal by default so there might be places where you need to add some additional imports to fix build errors. You might see a bit of a speed up in build times due to the compiler having to do less work.

Potentially testable in Swift 5.10 (March 2024)

The following are mentioned on Progress toward the Swift 6 language mode, and while the wording seems open to interpretation it looks like these feature flags might be getting added in 5.10.

SE-0411: Isolated default values

Summary: Actor isolation rules will be changing for default arguments and stored property values

Compiler flag: -enable-upcoming-feature IsolatedDefaultValues

High level assessment: This could potentially introduce some fun errors to handle

SE-0412: Strict concurrency for global variables

Summary: An improvement to strict concurrency to cover global variables

Compiler flag: -enable-experimental-feature GlobalConcurrency

High level assessment: This could potentially introduce some fun errors to handle

SE-0418: Inferring @Sendable for methods and key path literals

Summary: A concurrency improvement that will infer whether functions and key path literals are sendable or not (currently you have to do some workarounds)

Compiler flag: -enable-experimental-feature InferSendableFromCaptures

High level assessment: Doesn’t sound like it should have any negative impact, could just make adoption of Sendable easier?

SE-0414: Region based isolation

Summary: A concurrency improvement that will allow non-Sendable values to be transferred if the compiler can determine a data race isn’t caused

Compiler flag: -enable-experimental-feature RegionBasedIsolation

High level assessment: Sounds like zero impact and would just make Sendable adoption easier

SE-????: Improved control over closure actor isolation

This one’s not on the main branch and the linked proposal is in draft, so not sure if it was included on Progress toward the Swift 6 language mode in error or has perhaps been folded into another proposal or just abandoned? (the link to the pitch is also broken)

Summary: A concurrency improvement to give the ability to define the actor isolation of a closure

Compiler flag: Unknown

High level assessment: Though it’s just a draft it seems like there’s nothing to cause issues in there, just a change that would make it easier to introduce concurrency

Not expected in Swift 6

SE-0335: Introduce existential any

This was previously going to be enabled by default in Swift 6 but has been deferred to further in the future, according to Progress toward the Swift 6 language mode.

Summary: All existentials will need to be prefixed with any. More info on SwiftLee.

Compiler flag: -enable-experimental-feature ExistentialAny

So when should I be doing all this?

Swift 6 doesn’t seem like it’s going to provide forwards compatibility, meaning a dependency built with Swift 6 won’t be compatible with a consuming library built with Swift 5. For example if you use a library like Firebase and they make a release built with Swift 6, but you’re still using Swift 5 that’s not going to compile.

The opposite should be fine though. If you start using Swift 6 then you’ll still be able to use libraries that are built with Swift 5.

So an instant adoption of Swift 6 isn’t necessary for everyone, most likely. But you may find the need to adopt it somewhat forced upon you by a dependency you use. But that’s only if you need to upgrade to their latest release once they adopt Swift 6, you can continue to use their older Swift 5 releases until you absolutely need that Swift 6 release. Though that may be sooner than you anticipate if there’s some new feature or fix you need from it!

Regardless of when you decide to adopt Swift 6, anything you can do to reduce the amount of work it would take, ahead of time, is likely sensible in case you find yourself forced into adopting it at short notice.

We write tests to prove that our code is correct now and in the future. If we want to do some refactoring some day then we can rely on “good” unit tests continuing to pass to give us confidence we’ve not caused issues. If the tests aren’t “good” then they potentially bring us no actual value.

Another example of when good unit tests are beneficial is when updating to new tooling. If a new version of iOS, Android or some other dependency of ours comes along and we want to know if our code works correctly on it then only good unit tests will tell us that, bad ones might still pass when the underlying code is completely broken.

What do good unit tests look like?

Some things that make good unit tests are when they:

• Validate that the subject under test behaves as it’s intended to, in detail:
  Given different inputs into the unit, do the correct outputs and side effects occur?
• Isolate the subject under test from other units:
  If unit A is used by unit B and unit B has some great tests that give coverage of unit A you might feel like skipping any testes for unit A. But what if unit B changes in the future and no longer uses unit A? Then you’ve lost all test coverage for unit A.
• Give meaningful coverage:
  100% code coverage doesn’t mean you have good quality unit tests, it just means that every branch of your code gets executed when you run your tests, not that there’s any validation that any of it is working correctly
• Probably more things that are important too, this isn’t an exhaustive list, feel free to make any of your own suggestions!

There are test examples that follow that have been written to be as generic and pseudo-codey as possible so they’re clear for developers from any background. Hopefully they make sense, feel free to comment if anything is unclear!

Verify expected values

A poor test example:

We call a function on the unit being tested and we verify that its delegate gets the expected function called:

But we’re just saying we’re happy with it being passed any value imaginable, which is unlikely to be what we really want.

The test will happily pass when our code is working as expected, but if it doesn’t continue to work as expected (perhaps in the future after a refactor) it will still continue to pass because the parameter has been considered meaningless.

An improved test example

Let’s verify that the delegate is called with the actual parameter we expect:

Sometimes it can be complicated to validate the parameters because they might be complex generated objects that are non-trivial to recreate in the unit test, but it may well be valuable to go to the extra effort.

Verify unexpected function calls aren’t made

A poor test example

Building on the example from above, if ADelegate has multiple function calls, such as onSuccess and onError functions, it’s worth making sure that only the expected one is called, as otherwise they could both be called if your code is incorrect and the following test would still pass, even though it’s not behaving correctly:

An improved test example

The following test would fail if both functions were called, thus catching a bug for us as early as possible.

Verify expected behaviour

A poor test example

The behaviour of a specific unit can vary wildly from another, so the tests will always come down to the specifics of what the unit is intended to do.

The following could be a good test if the unit is just mean to hold on to the value it’s given, but in most cases that won’t be all it needs to do, it will likely need to do something with that value. It might pass it on to another class while executing its behaviour.

An improved test example

In order to check that the unit is making use of the value as expected, in isolation from other units, you’ll likely need to use dependency injection so that you can mock out other units and just check that they get the right values passed to them

Now we know that the unit takes the value it’s given, reports it back through its own API (might not be necessary to have this API in a lot of cases of course) and passes it on correctly to its dependency.

Verify pre-requisites of your test

A poor test example

Let’s say we’ve got a class that should create something and store it somewhere, here’s a test that seems to do that pretty well:

We create the unit being tested and it’s going to be store the thing for us and we verify that it’s stored afterwards, awesome right?

An improved test example

What if another test already stored the value we’re checking for and then our class stops storing it? The test will still pass, but shouldn’t! To avoid this happening unexpectedly we could verify that the stored value isn’t there when we start the test as that will then cause a failure if things aren’t as we assume.

Even better is clearing the storage before and after every test to make sure it’s empty, though the verification of the stored value not being present is still valuable in case that goes wrong too.

How to get good unit tests?

It’s not the only way, but Test Driven Development helps you write great tests and makes you think about the tests right from the start, rather than being an after thought.

TDD seems to have a somewhat bad reputation with some people, but you don’t have to carry out TDD religiously, you can take some learnings from it and realise that writing tests sooner rather than later makes them better and saves time in a lot of cases.

What is TDD?

If you’re not familiar with TDD then this slide from a presentation at iOSDevUK, maybe as far back as 2015, sums it up succinctly:

You start by writing the simplest test you can think of and initially that’s going to fail because you have no actual functionality written (not even the unit that’s to be tested initially!). Then you write just enough code to make it pass, without about the bigger picture and the end goal.

A good example of this is that if you need write some code to sort a list then you might start by writing a test that checks that a sort function that’s given an empty list will return an empty list.

Then you write the sort function and merely return an empty list. Empty list in, empty list out, your test passes!

You’re still a long way from finishing, but you have a meaningful test and it passes. You then look for any opportunities to refactor your code to make it better (without making it do anything extra) and then you repeat the process by writing your next failing test, making it pass and so on, until you’ve got all the functionality necessary written and all the tests that prove it’s ready to go.

So we should do TDD?

It seems like it’s not for everyone and doing pure TDD can sometimes feel a bit slow and backwards as you’re intentionally writing incorrect code. If you like the approach, go for it, if not maybe you can skip some of the steps, so long as you still write the necessary tests. Instead of writing a sort function that simply returns an empty list maybe you can jump ahead a bit, but do make sure that you write that test to verify empty list in = empty list out etc.

Doesn’t TDD just take longer?

It’s always super tempting to just dive into writing the working code because you already know what you want it to do and roughly how it looks, but getting to that working code doesn’t mean you’re done, you still need to get those good unit tests written, and how often have we all written a load of working code quickly and then taken much longer to add the unit tests (or maybe given up early because it was taking too long), so maybe it’s not slower to do TDD (if you also want those good UTs)?

Trust me bro, I’ll just add the tests at the end!

It can be very difficult to consider what unit tests are necessary for a piece of code that’s already been written, especially if it’s quite complex. If you wrote the tests as you wrote the necessary bits of code you’d probably have all the right tests without having to think too much about it at each step.

Equally, trying to write tests at the end will likely be quite difficult if you’ve not written your code in a testable manner. Maybe you can’t easily validate the behaviour of the unit because it’s all hidden away and strongly typed.

Dependency injection is a great way of making your code testable, allowing you to mock dependent classes so that UTs can control their behaviour in specific ways or validate values passed to them. Having to go back and modify your code to make it testable can sometimes be quite a big undertaking, with TDD you’d have realised very early on that it was going to be necessary, so would have been quicker to take care of.

Ok, I’m sold on the benefits of TDD, what’s next?

Practicing some TDD “katas” (because using martial arts terms is super cool) like the sorting example above can give you a great sense of the benefits of TDD that you can then take forward into your general development work and hopefully think about tests earlier in the process.

The katas are short exercises, maybe 15–30 minutes, describing the requirements for a class that you can test your TDD chops on.

Here are some links to kata exercises you can try out:

• TDD Manifesto katas
• Kata-log katas

A quick search for “TDD katas” will find you even more to choose from!

Summary

• Write tests as early as possible to make sure you’re writing code that’s testable, don’t leave them all to the end
• Isolate the subject under test from other units
• Cover all units with their own tests
• Make sure your tests:
  • Verify a wide range of different inputs (e.g. nil, empty strings, negative values etc.)
  • Verify expected values, function calls and other behaviour
  • Verify unexpected function calls aren’t made
  • Verify pre-requisites of your test (e.g. side effects aren’t yet valid)
• A high percentage of code coverage may well be a meaningless statistic and we don’t just want to be able to brag about our percentage, we want good unit tests to watch out backs
• If you’re reviewing a pull request, try to look out for bad unit tests!

Writing good unit tests was originally published in Dev Genius on Medium, where people are continuing the conversation by highlighting and responding to this story.

Previously I wrote about my Swift Package ProvisioningProfile, which extracts when your (iOS/watchOS/tvOS/macOS) app’s provisioning profile is going to expire.

If you’ve got a load of your own apps on your device(s) (or other people’s devices) but they’re not on the App Store or TestFlight then you‘ll have experienced the struggle of the provisioning profile expiring and the app not launching, potentially at a crucial time when it was needed and there’s no dev machine nearby to reinstall it!

I’ve got (too many) personal apps on my iPhone, iPad and also some on my the iPads belonging to my kids, which is quite a lot to consider if you want those apps to always be available, especially with them all expiring at different times throughout the year!

The original plan for ProvisioningProfile

Originally I created the ProvisioningProfile package as an easy way to show the expiry date in an app and even show alerts or notifications when the expiry date was nearing. That would work ok for most of my regularly used apps on my iPhone, but there are some that are used less regularly and I don’t use my iPad much at all so those apps would expire without me realising (and my kids would probably miss/ignore any notifications on their iPads).

So I started thinking about what the next option would be and I figured I needed a cloud database to capture this information and allow me to keep an eye on it myself. So that’s what I did next!

Whenever I see people talking about cloud databases I see iCloud and Firebase as the forerunners. iCloud would be pretty good for this use case as all my apps are for Apple devices, but I’ve heard there can be issues with it and having dabbled with Firebase’s realtime database previously (and found it to be super straightforward for simple stuff like this) I figured I’d stick to what I know!

Firebase & ProvisioningProfile (and yet another app)

So the basic idea is that you create a single project in Firebase that houses the realtime database and you register all your app bundle IDs to it so that they can update the database.

I made a simple “profile logging” Swift package that would use the ProvisioningProfile package to extract the expiry time and insert it into the Firebase database, along with some useful information such as the device name, app name and version. If you follow the Firebase realtime database tutorial it’s fairly straightforward to update it. This is basically what my package does:

I then made yet another iOS “tracking” app (but who doesn’t love creating new apps??) to read from the Firebase database and display the information, as well as scheduling notifications for each app expiring, which of course I’ll actually notice and deal with appropriately! And of course this “tracking” app also logs its profile expiry to the database!

This has proven to be a pretty nice solution for my use case. It’s not too awkward to integrate it into a new app and then it silently keeps the database up to date:

• Setup your new app on the Firebase console (simply by adding the bundle ID to the existing Firebase project, super quick)
• Download the GoogleService-Info.plist from Firebase and add to the app
• Add the “profile logging” Swift Package to the app
• Call the package’s API to log the expiry when the app launches

No need to add any UI to display the expiry date or to mess around with scheduling notifications, that’s all handled by the “tracking” app separately!

And here’s a look at the “tracking” app”

Some things to bear in mind

Potentially missing changes

With this solution, if I install a new app on a device (or the profile is updated for an existing app) and I don’t open up the “tracking” app to pull down its expiry date then it’s unaware of that app so it could then miss the expiry and not notify me. It’s not a likely issue for my use case but it could be for some. I think Firebase might be able to send out database update notifications to apps such that it could deal with this scenario though.

False alarms

If I install one of my apps from the App Store over the top of a dev version, with my current approach, the “tracking app” will still warn me the app is going to expire, even though it won’t. This is because the App Store versions of my apps don’t update the database. Not a huge issue for me to manage but your mileage may vary. One solution could be to keep the database updated from App Store apps too, removing the entry for the app (or flagging it) if there’s no profile found when running the app (though simulators also don’t have profiles available so keep that in mind).

Firebase app limits

Firebase has a limit of 30 apps per project on free plans, which could be problematic for those with many apps. You can open your wallet (though I’m not sure how much the limit goes up to for paid plans) or you might be able to find a solution that batches up your apps into multiple projects and then get the app to pull down from each project?

Firebase already in use?

If you’re already using Firebase in your app for something else then I’m not sure whether this will create an issue. You’d have a specific Firebase project configured in your app for the main functionality but would need a different Firebase project to receive the profile expiry details. I imagine there’s probably a way you could setup your app to start with one configuration, log the expiry and then switch to the main configuration, or maybe you could log it to your main Firebase project and then get that to pass it on to the tracking project (some custom server magic, which might not be everyone’s cup of tea!).

Firebase security

Security of the database could be a concern. In my setup I need the database to be open to modification by anyone so the plethora of apps can make their updates silently. So I imagine an attacker that found my database could update/delete the data fairly easily. I did look into this a bit and Firebase does offer various solutions but I’m not sure any of them really help my situation much. I did limit reading of the database to my own account and integrated Firebase authentication into the “tracking” app, but I didn’t want to require authentication in all my apps as that would affect the UX and integration complexity too much.

For my use case I only need this in development builds. All my non-App Store builds are debug and the App Store builds are release, so I’ve skipped the logging in release builds and also excluded the GoogleService-Info.plist (which lists everything you need to access the database) from release builds. So at least that keeps the database a bit more secret.

A curveball from Apple

In iOS 16 Apple changed UIDevice.name to no longer return the user’s chosen name for the device (which defaults to something like “Chris’ iPhone”) but instead a generic name, unless you jumped through some hoops to get approval for accessing the user’s device name. That was a shame because it was very useful for me to differentiate devices, but I totally understand why Apple changed it.

I looked into whether I’d be able to jump through Apple’s hoops but it didn’t seem like I would so I had to come up with an alternative. If you’ve looked at the gist for the logging code above then you’ll have already seen what I did. I basically swapped out the devices name for a combination of UIDevice.identifierForVendor and the model of the device model (which I get from DeviceGuru). My “tracking” app has the ability to give a recognisable name to a device in the database so I can re-label it to something more meaningful.

The device model gives me a clue which device it might be (I have a different iPad model to my kids, though they both have the same model) and then I have to use some logic to figure out which vendor ID identifies which similar device based on the apps that have been logged or the time that the logging happened (e.g. I just installed app X on my son’s iPad so I can tell that this vendor ID in the database is for his iPad).

With my small data set this is manageable, but if you’ve got a lot of different devices you’re deploying to then you might need something a bit better!

In the earlier days of SwiftUI I was putting together a card game (for funsies) and had most of it working quite nicely but couldn’t figure out how to animate the cards from the deck to a player’s hand. iOS 14 was in beta at this point and I found references to its new matchedGeometryEffect modifier, which seemed to be the answer. Unfortunately, I wasn’t in a position to be making use of beta features at that time so the project came to a standstill.

Fast forward to now and I’ve finally found myself going back to this concept of moving playing cards around in SwiftUI and can now happily make use of matchedGeometryEffect! I struggled for a bit to figure out how to get it working and I didn’t come across any blogs that dealt with the specific issues I was facing (they were all focussed on moving Views around for ‘hero animations’, which is a bit different), so I thought I’d write up my findings in the hope it helps someone else!

So to summarise the behavior I was after:

• Cards don’t change size as they move around
• When the cards need to move between different hands and/or the main deck of cards they should move smoothly in a realistic manner

For those eager to get to the complete code solution you can check out the full example project on my GitHub here. For those who’d like a walk-through of the process, read on!

Step 1: Models

First off we need some models for the objects in our card game:

We’ve got a Card and a Hand, which contains an array of Cards.

Card is Identifiable, as is often required for SwiftUI (so it knows how to handle the introduction or removal of a view that’s different from another view), and Equatable to facilitate finding the card in an array. The only other data the Card has is a number to represent its value (no suits or face cards in this example).

Hand is also Identifiable for the same reasons and it’s an ObservableObject because our Views are going to want to know when cards are added to the hand, or removed. The cards array uses the @Published property wrapper so that it automatically reports changes to Views that are watching for changes.

Step 2: Game state

Next up let’s create an object to hold the state of the game:

This simply holds a deck of cards (represented by the Hand model as it does the job we currently need it to) and an array of Hand models representing the players in the game.

The init sets up the deck with 20 cards, shuffles them, then creates two Hands with one Card each to start things off.

Step 3: A View for a Card

Next up let’s create a View to represent a Card:

Fairly straightforward for the most part. We’ve got a ZStack with two RoundedRectangles to represent the card background and border and on top of that, we render the card’s value with a Text.

We’ve got a namespace property, of type Namespace.ID, being passed into the View. This is a requirement for matchedGeometryEffect, providing the context that the card exists in. In this example, I’ve used the Card’s value as the id for matchedGeometryEffect as that’s unique enough to identify an individual Card as it gets moved between Views.

Following some other blogs I found, one of the first issues I had was that, while I could get the cards to animate to their new location, there was a fade animation being applied. The card seemed to disappear from its old location instantly and then faded back in as it moved to its new location:

This behavior wasn’t shown in the other blogs I saw, so I’m not sure if this is a difference between iOS 14 and 15 or something subtly different in my code.

After a lot more digging I stumbled upon a blog that pointed out that this is the default transition style applied to views when they animate (in any scenario, not just with matchedGeometryEffect). I looked into changing the transition to something that didn’t affect the opacity and eventually I found that using a scale transition, set to 1, was the best option I could find for the desired “don’t affect how the View looks, just move it to the new location”.

Another thing I’d like to call out here is that other blogs I read, for hero animations, said you should place the matchedGeometryEffect modifier before any frame modifiers to get the desired effect. For hero animations, you want to allow for a change in the frame so this makes sense. In my example, the frame is staying the same so it’s not so necessary. In fact, at one point in putting together my example, it had to be placed after the frame, otherwise, the animation was all messed up. I can’t actually reproduce that issue now but it could be something you come across so remember that the order of view modifiers often matters! That’s just good advice for all SwiftUI work to be fair!

Step 4: Previews and Namespaces

I found that I had to get a bit inventive with the PreviewProvider struct for this View, due to the namespace being passed in and the previews property being static:

Basically we define a View that contains the CardView and can pass in a Namespace.ID and that’s what we return from previews.

Step 5: A View for a Hand

Next up let’s create a View to represent a Hand:

Here we’ll pass in the Hand, Namespace.ID and closure for when a card is tapped. The Hand uses the @ObservedObject property wrapper so that the View responds to changes published by the hand (i.e. adding/removing of cards) and will rebuild itself as necessary.

We simply have an HStack which renders each Card in the Hand and if any of them are tapped it calls the closure that was passed into the View.

Step 6: A View for the deck

Next up let’s create a View to represent the main deck of cards:

Very similar to the HandView, but we render only the last two cards in a ZStack, so they’re on top of each other, just like a deck of cards stacked up.

Step 7: Putting it all together

Finally, let’s put it all together into the main ContentView:

The ContentView creates the GameState and holds on to it (depending on your hierarchy you may want to pass this into the view). It also provides the top-level @Namespace context for the matchedGeometryEffect that gets passed down to each CardView.

This View is pretty straightforward otherwise. There are some brief instructions at the top explaining how you can interact with the cards, followed by the DeckView and a HandView per Hand in GameState. Each HandView also has a ‘+’ Button that allows you to pull a CardView from the DeckView into that HandView and whenever you tap on a CardView in a HandView it moves it back to the DeckView.

Moving the cards between the deck and a hand is simply done by moving the Card models between the relevant Hand models, within a withAnimation closure so SwiftUI knows we want it to animate. The matchedGeometryEffect and transition modifiers in CardView provide the information to SwiftUI regarding how it should carry out those animations.

And that’s it! As mentioned earlier, there’s a full example project available on my GitHub here.

Feel free to leave any comments with feedback or questions!

Issues you may still face

Different iOS versions

matchedGeometryEffect is available from iOS 14, though I’ve only tested my example on iOS 15, so if you’re trying to use it on iOS 14 there could be some differences. The example compiles for iOS 14, but SwiftUI is still pretty much in its infancy so different OS versions can be problematic!

Duplicate view errors

I had some trouble getting the observing of cards moving between the different Hands to work properly. Sometimes the animations wouldn’t happen and the console would get an error logged about duplicate IDs appearing for different Views at the same time. So that could be something that you end up running into and can be tricky to figure out how to avoid it.

The setup I had where it wasn’t working was before I introduced the DeckView and just had the ZStack of it included directly in ContentView. Because that wasn’t able to observe the Hand of the GameState’s deck it meant that SwiftUI would rebuild some of the Views when the cards moved in/out of the deck, but didn't think the deck itself needed rebuilding. So just try and make sure anything that can change is being observed so SwiftUI knows it needs rebuilding!

ScrollView problems

Putting the cards in a ScrollView could be desirable for the player’s hand, otherwise it could easily go off the screen, especially on a portrait iPhone. Unfortunately that doesn’t work well in terms of the transition. When the card is moving from the deck into the hand it renders in the ScrollView’s clipped canvas rather than on top so you see it sliding in out of nowhere. Hopefully this is something that will be fixed in a future iOS version!

Moving views around in SwiftUI was originally published in Dev Genius on Medium, where people are continuing the conversation by highlighting and responding to this story.

For many years I’ve used MFMailComposeViewController in my iOS apps to help the user send feedback emails to me. It’s a nice way of keeping the user in my app and just popping up an email composition sheet to let them say whatever they want to say quickly and easily.

This approach uses the Mail app of iOS, provided by Apple, which would generally be setup with a user’s iCloud email account and any others they’ve setup in the app themselves.

But it’s entirely possible that a user doesn’t have an email account setup in the Mail app. Maybe they have a preferred app they use like Gmail, Outlook etc. If that’s the case you’d just get an error from MFMailComposeViewController that it wasn’t possible to send an email with it.

In the past I’d always taken the easy way out and just displayed an alert saying the email couldn’t be created and listed my email address so they could go off to their alternative email app to write their feedback. I would sometimes even copy my email address to the pasteboard so they could easily paste it into their email app rather than having to memorise it.

Since iOS 14 a user has been able to setup a preferred default email app, which will then be opened for any email related OS functionality, rather than the Mail app. So a better approach is to go back in time and use the old classic mailto: URL and ask iOS to to find the right app to handle it, i.e. the default email app they’ve selected.

Here’s a code example showing you can do this with a predefined subject and body for the email:

Simple as that! Your users have less friction to get in touch with you if they’re not using the Mail app so you’re that little bit more likely to get any feedback they want to share with you.

You can read up more on other options for mailto: URLs here.

With only the mailto: approach you do lose the benefit of keeping the user in your app, so if they want to continue using your app they need to find their way back, which for less experienced users could be confusing of course.

You could keep using MFMailComposeViewController by default and just fallback to mailto: if the Mail app isn’t setup, though that would ignore the user’s preference of using a different email app, which is could send them into a fit of rage! It unfortunately doesn’t seem like there’s any way to determine whether the user has a default email app that’s not the Mail app setup, based on this Stackoverflow question.

Something that can often be troublesome in iOS (or tvOS) development is presenting alerts at random times while other things might be happening in your UI.

In iOS 8, Apple deprecated UIAlertView, which didn’t require a specific UIViewController to be presented from, as is required in the UIAlertController that replaced it.

Suddenly app developers needed to specify which UIViewController would be presenting the alert, and with that came the problems of “what if it’s already presenting something” and “what if it’s in the process of presenting/dismissing something”.

If you try and present an alert (or any other UIViewController) in one of those scenarios it will silently (just an error logged to the console) fail to present, which could leave your app in a broken state or, at the very least, the user is left without some information/choice you intended them to have.

I came across a partial solution to some of these problems when taking over an existing test app at work, where it would queue up alerts in the case that something was already being presented. It was interesting but it didn’t fully solve the problem so I started looking for a better approach.

That’s when I came across William Boles’ article on queueing and presenting alerts in their own UIWindow. I took what he’d provided, modified and extended it a bit and turned it into a Swift package which you can checkout on GitHub: AlertPresenter.

It’s a great way to be able to present alerts without worrying about the exact state your app is currently in. Sometimes that’s fine, other times you might need something more involved, so this might not be the right solution for everyone, but for fairly simple apps or apps that are being used to test a framework/library it should be a great help!

In Part 1 we looked at how we could generate the public API of our Objective-C/Swift frameworks in the Swift language. But what if we want to see how our public API looks in ObjC? Most people have moved on from ObjC so it may not be such a big concern for many, but some of the devs using your frameworks might still be using it from ObjC, so it may be worth making sure you’re not breaking the public API for them unexpectedly.

Objective-C

In an ObjC framework the public API is defined by the umbrella header, which includes all the public headers that exist inside the framework. One approach to generating a listing of the public API is to walk through each public header listed there and include everything that’s defined in them.

I’ve created a script that does exactly this in the GitHub example project, which generates the following output for the ObjC framework:

FOUNDATION_EXPORT double ObjC_FrameworkVersionNumber;
FOUNDATION_EXPORT const unsigned char ObjC_FrameworkVersionString[];
typedef NSWindow XPWindow;
typedef UIWindow XPWindow;
@interface OCClass : NSObject
- (NSInteger)getInt;
- (NSString* _Nonnull)intToStringWith:(NSInteger)integer;
- (NSString* _Nullable)tryIntToStringWith:(NSInteger)integer;
- (XPWindow* _Nonnull)getWindow;
- (void)macFunction;
- (void)iOSFunction;
@end
typedef NS_ENUM(NSUInteger, EnumValue) {
kOne,
kTwo,
kThree
};
struct OCStruct {
enum EnumValue enumValue;
};

That looks pretty good, all the types defined in the code are showing up, even for different platforms (see the inclusion of the macFunction and iOSFunction methods), so you only need to run it for one platform and you get the public API of everything (the script could be modified to only show the output for a single platform if desired).

Swift

Swift frameworks already have a file that describes the public API in ObjC, the <framework name>-Swift.h file. It’s the file you’d import into your ObjC code if you wanted to make use of your own Swift code within your framework.

The raw -Swift.h file has quite a lot of irrelevant noise at the top (at least for what we want from the file), so I put together a script in the GitHub example project that would remove that and just leave what we’re really interested in.

For the Swift framework here’s the output:

// Generated by Apple Swift version 5.4 (swiftlang-1205.0.26.9 clang-1205.0.19.55)
SWIFT_CLASS(“_TtC15Swift_Framework6SClass”)
@interface SClass : NSObject
- (NSInteger)getInt SWIFT_WARN_UNUSED_RESULT;
- (NSString * _Nonnull)intToString:(NSInteger)int_ SWIFT_WARN_UNUSED_RESULT;
- (NSString * _Nullable)tryIntToString:(NSInteger)int_ SWIFT_WARN_UNUSED_RESULT;
- (nonnull instancetype)init OBJC_DESIGNATED_INITIALIZER;
@end

Well, it’s a bit less than we might have expected, but you have to remember that many Swift types and features aren’t available to ObjC, so the Swift enum is left out and even the Swift class would have been left out had it not been correctly marked for exposure to Swift by inheriting from NSObject and tagging each function with @objc.

Conclusion

Nice, with part 1 and part 2 we can now generate listings of our public API in both ObjC and Swift, for both ObjC and Swift frameworks! Integrate it all into our way of working (pipelines, pull requests etc.) and we’ll never unexpectedly break our public APIs again (maybe)!

Disclaimer: I’m no shellscript expert by any stretch of the imagination so these scripts may make your skin crawl, who knows! Happy to receive feedback!

As with the scripts in part 1, you should keep an eye on how long these scripts take to run. You may well find that the more code you have in your frameworks the longer they take to execute and might noticeably slow down your build time. You may want to run them only in your CI pipelines (or manually if you don’t have CI!).

As pointed out in the updated version of part 1, the solution I gave to generate the Swift API from an ObjC framework actually only works if your framework is compatible with macOS. So if you blindly import UIKit, for example, it will fail to generate the API. You can put a load of #ifs into your code to make it compile, but you then just get the macOS API out, so if you’re actually just supporting iOS then quite possibly a lot of your public API wouldn’t be included. Hopefully in part 3 I can present a better solution! And we still haven’t covered multi-language frameworks yet!