iOS extensions using swift
Last year around early September 2014 I created my first custom keyboard for iOS in swift. I remember those days were a debugging nightmare: Xcode couldn’t debug swift and an extension without a improbable macumba of Build/CleanAll/Stop/ChangeSchema/Rebuild/Debug, and the total lack of a managed swift eco system (i.e. using cocoa pods) was hurting me so much; I wasn’t motivated enough and extensions didn’t look a good swift playground so I quit the attempt with an “almost working” iOS custom keyboard and an idea to be resumed in the future.
Almost 8 months later I got back at that idea and found that now an extension can be developed and tested almost like any other app, still there are some traps that have yet to be covered:
Neither cocoa pods (0.37.1) or carthage (stabled 0.6.5, 0.7.4) have been able to create a project that could go from “simulator” to proper “archive and publish” version. Mostly because as soon you pimp your extension with external frameworks these frameworks may not be properly configured for being used by an extension and they require some small tweaks.
This below is my promemoria to achieve a working building system
- let’s say my extension depends on 4 swift frameworks, I don’t have to link them against the extension itself but against the containment app
- whenever possible, avoid frameworks that depends on other carthage frameworks because they may lead to annoying sub carthage dependency with embedded ‘Frameworks’ that need to be cleaned (see below)
- each frameworks must have the following build settings
“Require only API-Extension safe” = YES
“Embedded Content Contains Swift code” = NO **to be honest I don’t understand this **
“iOS Deployment Target” >= 8.0 (some framework may have 7, but extensions must have 8.0 or greater)
- linked frameworks can not contain frameworks as well i.e:
AlamofireObjectMapper depends from both Alamofire and ObjectMapper, using carthage these two dependency are built both inside the AlamofireObjectMapper and externally. Once you submit your app ItunesConnect will complain that this is bad, luckily in this case simply removing the folder “Frameworks” from AlamofireObjectMapper.framework folder itself is enough to fix the problem (anche keep the build working). Note, the same should be valid for other embedded frameworks in frameworks.
In my experience when working with swift and app extensions the most important promemoria has been:
do not just test on device and simulator because the real problems come with distributing the build itself. So before anything works, just create a simply dummy extension project with all frameworks you may need and try to validate it against ItunesConnect. This may save you from replacing code of frameworks not yet ready to be included by an extension (I look at you ReactKit and SwiftKit!)