MartinRogalla

I work with feature branches for iOS development as follows:

Whenever I want to create a new feature or fix a bug, I create a new branch. I am responsible to rebase and keep the branch up-to-date until it is reviewed and merged. When the branch is merged into master, using @KrausFX's fastlane tools we automatically build, test, submit a build to testflight and create a pre-release with the build number on GitHub. The appropriate people then review the App and submit a release for review by Apple whenever they're ready. Once the App is approved and released we create the corresponding official release on GitHub.

Works well and keeps us productive.

As I may have overlooked something, could you pinpoint where in this workflow you would have issues?

Have been doing iOS programming with Swift 2.5 days per week for a bit less than a year now. The first step I took was to read through Apple's Official Swift Language Guide[0]. After completing this I followed the Stanford course on iOS Development with Swift[1]. I didn't spend much time on this, I did this in a Friday afternoon(language guide) and full weekend(watching lectures), since I believe more in learning by practicing.

I've really come to like Swift as a language, since it's concise and simple. The iOS SDK however is not so much fun. Learning the iOS SDK will take a lot of time before you develop routines to approach your problems. I'm still learning about strange behaviour from the SDK and getting frustrated by it every time I use it. It's important to keep things fun, look through the trending Swift repositories on GitHub, follow #iosdev on Twitter and /r/iosprogramming, you will learn a lot if you keep up to date with these sources.

Some of the habits I've created, which might be handy to other people:

- I manage dependencies with CocoaPods, with no dependencies residing in my repository.

- I don't use storyboards or xib's at all. Everything I do is with SnapKit[2]. This takes some time to learn, but it greatly improves the diffs and overview on how the ui elements are constrained and set up.

- I use API endpoint enums which get called by an API Handler, which uses Alamofire[3] to execute the api requests.

- I try to use as many tools provided by Fastlane[4]. Especially if you're developing many Apps, or incrementally building an App, releasing a new version every two weeks: automate all the things. Otherwise you will waste so much time simply waiting for a process to complete.

Side note(if you're interested):

I'm currently developing a tool called Evans(will write a blog post as soon as it's reasonably finished), which performs all kinds of routines automatically. It for example listens to GitHub comments like '@evans screenshots' on a pull request. Evans then emits a request to one of the build slaves, which retrieves the branch, builds the project and runs the screenshot routine, puts the screenshots in an s3 bucket and posts a link as a response in the pull request.

[0] https://developer.apple.com/library/ios/documentation/Swift/...

[1] https://itunes.apple.com/us/course/developing-ios-8-apps-swi...

[2] https://github.com/SnapKit/SnapKit

[3] https://github.com/Alamofire/Alamofire

[4] https://github.com/fastlane/fastlane

I can't really give a comment on this, since I haven't developed on a 8GB MBP. I think you should just expect a performance decrease once you're running your VMs next to your development setup. If you run XCode with your iOS Simulator next to it, I don't think you'll notice a large performance difference.

I recently bought a 2015 13" MBP w/ 16GB precisely for professional iOS development. Works like a dream and is amazingly portable. I would really suggest to get 16GB memory if you're looking to run multiple vagrant boxes.

Specs of my 2015 MBP 13": MacBook Pro (Retina, 13-inch, Early 2015) | 2,9 GHz Intel Core i5 | 16 GB 1867 MHz DDR3 | 250GB Flash Storage

That is incorrect. I'm writing this on a 2015 13" MBP w/ 16GB.