That process is actually pretty seamless, all things considered, but an automated approach would be the next obvious step. So for now, we’re just kicking builds up to iTunes Connect manually via Xcode. I hope that solution has some finer-grained control over which commits and which branches trigger this. I would imagine that as Apple improves this process, this would just be a checkbox instead of a custom post-hook script. Xcode bots do allow post-hooks, which means that if the API to upload to iTunes Connect was publicly available, we’d be able to push those builds directly to iTunes Connect. There was a workaround, but even still, without the ability to upload those to builds to the new TestFlight portal, it wasn’t all that useful to have build archives hosted on the machine running Xcode Server (which was in this case just my normal laptop). The unfortunate part was that I never got fully finished because there is apparently a bug in Xcode Server that doesn’t appropriately download provisioning information, so the automated builds couldn’t be code-signed. I recently installed Xcode Server and set up a CI bot within Xcode. Xcode bots seek to solve at least part of this problem – and may eventually solve the entire problem. If something changed about the provisioning profile, one developer could make the change, give the information to the build server, and no one else would know, care or be interrupted from their work. This automated process was very useful, especially for provisioning. When it was important to send out a build to testers or non-developers, we just clicked the button in TestFlight to make the most recent build available. Changes to master would automatically trigger our Travis CI build server to grab the source, build it, verify the build and upload it to TestFlight. Someone else must review the work before accepting the request, and acceptance will merge the branch into master. When work is finished, we create a pull request for the working branch. We do our work on branches off of our main development branch (which for us, is just master). Prior to Apple acquiring TestFlight, we had a pretty solid automated process for building and deploying to testers. In this particular case, we’re doing a bit more work to deploy to testers than we had done before Apple took over TestFlight. As has happened in the past, there have been times our workflow has fit directly into Apple’s vision, there has been times where a little more work was required, and there have been times where we have been forced to change our workflow. Hopefully, many of those improvements will address different types of companies and different workflows. So, it stands to reason that Apple is already working on improvements and additions to this process of deploying to internal and external testers, and to the App Store. This applies to SDK developers even moreso: an early, ugly API decision can cause problems for years for many, many developers. As we become more comfortable with the problem and its solution, we can craft a more appropriate API for that solution. Our first shots at solving new problems are often ugly. Of course, many of us knew then what most folks know now: private APIs are often the beta version of what will become a public API. The argument was often that Apple was being anti-competitive and screwing the little man, pre-emptive Sherlocking, if you will. (In general, at least everyone is allowed to make mistakes.) For example, it was only a few years ago when a private API that Apple used in one of their applications was a cause for protest. This has been my experience with Apple as a developer over the last decade: Apple waits until things are well-polished and tested prior to release. I’m assuming that we’ll see more and more functionality rolled into TestFlight. Other improvements to the rest of the process for code signing and distribution system have been welcome as well – I rarely have to go into the developer portal and manually enter things these days. Once complete, your app package has been uploaded to the iTunes Store.Since switching over to Apple’s TestFlight, we’ve been pretty pleased. The clear versioning of applications, easy internal and external test distribution, and having App Store distribution hooked into the same system is actually really great. It will will take a few moments to authenticate through the iTunes Store Then, run Application Loader (Download/Install Application Loader 2.9 if necessary): open -a /Developer/Applications/Utilities/Application\ Loader.appĮnter your iTunes Connect Apple ID and Password and select "Next" app file with a "Release" schema: xcodebuild -target "$”
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |