To get around this, the framework should be embedded and signed only once at the app target's level and then any other target which uses it should choose to not embed it.
The fix is straightforward but can sometimes be hard to spot if you're new to modularised codebases. This is due to the fact that there can't be more than one bundle with the same identifier. The app builds, runs and archives without any issues but as soon as it is uploaded it to App Store Connect, an error occurs:īy embedding and signing multiple times, we're creating duplicate copies of the same bundle, which causes an upload error. Each of these embeds and signs the framework. Let's consider now that the new SwiftUI module is a framework instead (in an Xcode project) and is used by different targets.
#FASTLANE MACOS ARCHIVE#
Now that we've seen an archive error, let's take a look at an example of an upload error. Note that this error seems to be specific to Xcode 13 and does not seem to be a problem on Xcode 14. testTarget ( name : "ScheduleTests", dependencies : ) ] ) Package.swift // swift-tools-version: 5.6 import PackageDescription let package = Package ( name : "Schedule", platforms :, products : ) ], dependencies :, targets : ). So what's happening? Well, after multiple attempts at fixing the error, it turns out that even though the new package is being imported by a target with a minimum deployment version of iOS 15, a minimum iOS version needs to be set under platforms in the Package.swift to make the error go away: After looking at some related Apple Developer Forum threads, it seemed that if an app has a minimum deployment version of iOS 11 or higher, it should not be built for that architecture. The problem here is that SwiftUI is not available on the armv7 SDKs, which is causing the compiler to not find any SwiftUI symbols.
Looking at the build log above, it looks like the app is being archived for armv7. But as soon as the release pipeline is run, there is an error related to archiving the application: Time goes by and the next release day comes along, with a lot of excitement on getting feedback from users on that new view. The app can be built, the tests run fine and the new view looks great, the app is now using SwiftUI! 🎉 The new module is then imported by the application target and displayed when needed. Package.swift // swift-tools-version: 5.6 import PackageDescription let package = Package ( name : "Schedule", products : ) ], dependencies :, targets : ). We want to introduce a new feature which is built entirely with SwiftUI, so we create a new module called Schedule (as a Swift package): Let's consider a modular iOS application which defines iOS 15 as the minimum deployment version. On the other hand, there are some errors which are specific to archiving an application, a process that usually only happens when we need to generate an artifact which then needs to be distributed. Archiving errorsīuild errors are easy to spot as an app is usually built on the CI numerous times every day. Let's take a look over the following sections at two different errors that can happen on release day and can certainly be tricky to debug. While some of theses issues are trivial to fix, you want these kind of processes to go as smoothly as possible and, in the case of a release pipeline, gain confidence that the app will go out to users in a swift manner, rather than having to spend time fixing errors.
When a pipeline is not run often, any issues with it will go unnoticed and will only creep up when the pipeline is next needed. A great example of this is a release pipeline, which automates archiving an application, signing it and submitting it to App Store Connect and is only run when the app is ready for release. MotivationĪs an iOS developer, there are certain CI pipelines which are crucial to the delivery of an app but, because of their nature, they are not run frequently. If you missed the talk and would like to watch it, I have made the recording available on my Youtube channel. Off the back of it, I thought it would be a good idea to write an article going into the specifics of the talk and the motivation behind it.
#FASTLANE MACOS HOW TO#
Testing your release pipeline using FastlaneĪ couple of weeks ago I gave a talk about how to gain confidence in your release process at the Mobile Devops Summit, a remote event organised by Bitrise.
0 kommentar(er)
