There’s more than enough code signing invective washing around the internet already, so instead of moaning about all the ways the process is confusing, I’ll start with a compliment: for new solo developers, xcode typically just works for signing, I think Apple have done a decent job. Unfortunately if you need to run a CI job for your app or otherwise sign from the command line or use multiple certificates and profiles, things get tricky.

In this article I intent to talk, at high level, about some of the decisions we need to make when laying a out a green field JavaScript app. I’ll address four key problems which most medium to large apps need to address: How the code is organised and loaded How isolated units of code communicate How the app presents How the presentation is structured I’ll discuss why I believe selecting small well designed components to address each issue individually is preferable to a large monolithic framework.

In general I find unit testing on the iOS platform to be a pain. Xcode’s built in test library, XCTest, is very basic and whilst I’m reasonably inexperienced with iOS development, it does seem the community as a whole doesn’t really rate unit testing. Automated front end integration testing seems to have a much higher mind share. Now I’m not against this approach at all. As with any front end tech, there are limits to what isolated unit testing can achieve.

Meteor 1.0 dropped a couple weeks ago which prompted me to revisit it. I’d previously dabbled with creating a race picker for the board game Twilight Imperium so we could spend less time faffing when it came to game day. Whilst I found it to to be an enjoyable experience, like most people I had concerns around code re-usability. I also felt for that particular app I didn’t really need the coolest feature of meteor, realtime by default.

I am a “web guy”. I tend to refer to myself as a “Web developer”, not a programmer, or a software engineer. I like making web apps. Over the last year this has extended to making cordova apps for touch devices. This has entailed dabbling in some native code for plugin wiring, but essentially I’m still a web guy at heart. Javascript is my bread and butter, and I’m just fine with that.