What really excites me the most about iOS 8 right now is Remote View Controllers, which I mentioned around iOS 6. Right now they are presented as something you use to implement services (extensions in iOS parlance), but combine them with auto-layout and adaptable view controllers, and you have a setup for presenting your app on an iWatch or an embedded display, for instance in a smart cover or an AppleTV widget. Embedding widgets accross iOS and mac devices is also an avenue I hope we developers soon get to explore. :-)

Today I needed to work with an alertview, so here are two steps for pressing them:

`Given /^I press alert button (\d+)$/ do |index|
touch(“view:’UIAlertButton’”)[index]
end

Given /^I press alert button named “([^”]*)”$/ do |text|
touch(“view:’UIAlertButton’ label text:’#{text}’”)
end
`

Everyone else is doing it, so I figured I could play “bingo” as well.

My predictions begin with “one more thing” on the iPad event: iOS 6 and AppleTV are tightly linked. Developers will get access to iOS 6 betas within two weeks from the announcement, with another event where they go through all the cool stuff. But the AppleTV will be updated with an A5X processor and third party applications installed via the AppStore, and will sport Siri and iCloud integration in a way that makes it easier to use than ever.

The iPad 3 will be announced with an A6 processor, which has enough RAM to power the retina display. The A6 will be more or less identical to the Tegra 3. The iPad will ship with iOS 5.1, and will, together with the iPhone, get iOS 6.1 support this summer, iOS 6.0 will be AppleTV only. The iPad will of course get Siri support.

The main newcomer on the software platform will be Microsoft, shipping a full Office line (excluding MS Access) for iOS, multiplatform for iPhone and iPad, and with a tight AppleTV integration for presentation. The presentation will also focus on Microsoft and Apple having a great relation through iCloud.

iCloud will begin acting like more Dropbox in that it will let you share documents better between iOS apps and Mac apps, bringing iWork and iLife on the mac better integration with their iOS counterparts. This increases need for space, but the iCloud free space will rise. The iLife and iWork updates won’t be mentioned, but will come as a software update quietly a day or two after the show.

For a project I’m doing at work, that I hope will eventually be open source, I needed to have protobuf compiled for iOS. A colleague of mine showed me how it had been compiled on iOS 4, using these scripts, but with iOS 5 I ended up with binaries compiled for the arm architecture instead of the armv7 architecture.

Be aware that the iOS 5 SDK actually ships with a version of protobuf, but it’s a bit old, being version 2003001. And it only ships the binary, not the headers.

To compile protobuf, grab the latest source (which is 2.4.1 at the time of writing this) and run the following script (download script):

After running this, you should have a directory called /tmp/protobuf/arm that is compiled for your iPhone or iPad with the armv7 architecture. Copy that into your project and start using protobuf

Tomorrow I begin work at Trifork! There I’ll be doing iOS development, so before I begin I thought I’d like to share a bit about how I do my development now.

First of all, I use GitHub and Beanstalk for source control, depending on what client the work is for (for my own projects, I use GitHub). Mercurial is nice, but git and svn just work with XCode, so I stick to that.

Since I have source control, I can have continuous delivery. For that I use Jenkins. Jenkins is not good enough. It’s not great. It’s not beautiful. It’s not intelligent, easy, friendly, intuitive, or all those other nice words. But it works! I use the Clang Scan-Build, Github OAuth, Github, Pre SCM BuildStep, Redmine, SICCI, SSH Slaves and Xcode integration plugins, even though I’d get most things done by just adding a shell script. That gives me a build per commit, which is nice and reliable and brings the pain forward. Jay pain!

Of course, having this infrastructure in place begs for tests. Now I think tests for iPhone applications suck. Bigtime! The reason is that I hate deployment cycles. It takes time, and that time I’d rather use writing code, thinking about the application, solving real problems for my customer, preferably before he knows about them. If not that, I’d rather drink coffee, do chores in my home, or clean my pipes, rather than waiting for build cycles. It’s just an enormous waste of time. And tests for iOS drain time, as there’s no such thing as a unit test for iOS. Everything is an integration test or a user acceptability test. You always fire up the entire application before running any test.

So now I have that rant done, it’s great that I can leave my tests to Jenkins. It will perform them, and the output will get converted to what looks like a JUnit test so that it can get picked up by Jenkins’ tooling and be presented nicely. Jay!

Then we get to deployment. My clients communicate with me. A lot! This should be different like so, I changed my mind about this, I’ve found a bug if you do like this and that. It’s great! I love my users for this! It creates such a momentum! So how awful wouldn’t it be if I said “I’ll collect everything and give you a beta in three weeks”? Continuous delivery isn’t just delivery to me, it is to the users as well. For this I use HockeyApp. They’re a great bunch and really responsive, and while they just don’t support iOS 5 well enough yet, there is so much good there. My app gets auto-deployed up there and my client sees the new release, hits install and boom! Now he’s running the latest build! Crash reports get sorted by build numbers, and the guys at HockeyApp have told me they’re working at making the crash reports even more awesome! Jay!

So how do I follow up on these things? I have to admit, I’m a cheapskate, so I use Redmine. I would use Basecamp, and I hope to be using it, it’s so awesome, but so far it’s not been worth the extra cost. The day it is, I’ll run and buy it quickly. My problem with Basecamp and Redmine? I just haven’t seen how I’d integrate it with my scrum sprints. Yet. I’m sure they both can, and I hope to learn from people that are wiser than me in this regard.

Finally, after a deployment to the appstore, I use Flurry to keep track of where my users are at, both in version of the app (why don’t they upgrade! This new version is awesome! I need to tell them more about it!) and the OS (really? They’re still on iOS 4?? iOS 5 has been out a month now! Oh well, not everyone is like me). Also, I’ve rolled my own crash reporting that, should I have failed horribly, the users can get in touch with me or the client, with a detailed log of what went wrong.

So, that’s my work setup this far, and I’m quite happy with it. It still needs better scrum integration. It’s still too many pieces that don’t talk sensibly together. But it’s getting better knit together, and I’m looking forward to seeing how Trifork does it, how I can improve based on what they have to teach, and how I can improve the way they’re doing it. It’s going to be great! Those guys are brilliant, and I love working with brilliant people.

Finally, if you’re in the Esbjerg area, working with iOS, get in touch with me. If you’d love to start working with iOS, get in touch with me! There’s an NSCoder Night coming up soon, biweekly I hope.