So you're thinking of building an iOS app for that great idea you have. Awesome ! But if you're not an expert in iOS development you'll need to hire one to build it for you, or maybe you're thinking of using one of those cookie-cutting app makers, that promise "no coding required".
If you want something to stand out from the competition, or if you have some special requirements, your only choice is custom development, with "plenty of coding required". Assuming you're doing it the right way, which will be the subject of a future post, you'll soon figure out that this is going to set you back a certain amount of coin. Just be aware that the sum you're contemplating at that point, based on the quote you got from the developer, is most likely only going to cover the cost of development. Is that all there is ? Well, not really, you'll also need to consider some recurrent, or revolving, costs.
Why recurrent costs ? Well, for one, if you have the app published under your own account, which is probably going to be the case if you're building a custom app, there's the $99 annual membership fee for Apple's Developer Program. Beyond that you'll need to think about the maintenance of the app. What ? Maintenance, like car or building maintenance ? Exactly.
You see, what happens is, these apps are not built in a vacuum, from scratch. Instead they're built on top of an existent platform, the iOS system, which keeps evolving. No doubt you're familiar with the fact that Apple periodically issues updates to the iOS system, indicated by different versions, like iOS 2.1, 3.1, 3.2, 4.2, 4.3, and so on. All these updates add new functionality, and, here's the rub, sometimes change existent functionality. That's right, stuff that used to work in older and current versions of iOS will stop working in future versions.
Why's that ? Two reasons. The first one is controlled. It's called deprecation. As they go along, folks at Apple figure out better ways to accomplish the same thing, or in some cases, the old ways of doing things stands in the way of progress, or conflicts with new planned functionality. In those cases they flag some functionality as deprecated, and provide some alternatives. You're given a period of time, usually unspecified, between several releases, to migrate to the new functionality. That means that for the time being the old functionality still coexists with the new one, but at some point in the future, solely at Apple's discretion, it will go away, and if you didn't migrate, you'll be left hanging.
The other reason is uncontrolled. It's because of bugs and defects that are the usual unintended consequences of changing software code. Every time Apple releases a new version of iOS, that new version has new functionality, fixes for known problems, and new, not yet known, problems. That's the nature of the business.
The biggest changes to the platform, and the most potential for bugs, are when the major version changes. The major version is indicated by the first number in the versioning scheme. For example in version 4.3.5, 4 denotes the major version. When iOS 5.*.* comes about, you'd better watch out.
I've been building iOS apps for a living for more than a year now. Based on that experience I can tell you that if your app has a fair amount of functionality, touching different areas of the platform, chances are high that it will break on the next major release. I had problems both when iOS 4 was released and when iOS 5 got released.
You may ask, how come, since iOS 5 hasn't been released at the time of this post. That leads to the solution. You see, Apple issues beta releases available for developers prior to the official releases. So all you need to do is have your developer proactively test the app on those betas, as they come along, and look for issues. This gives it the "hidden" nature of the cost. You can't know in advance how many problems you'll encounter. So you'll need to budget for that. On my latest project, which took about a year to develop, I had to spend a week to fix problems in iOS 5 beta.
How can one fix those problems ? In some instances they are problems in Apple's code. In those instances the developer must file a bug report with Apple, to let them know about the problem. The developer should next look for possible workarounds, because even if a bug report has been filed, there's no guarantee that Apple will fix it in time for the next release. You can gauge the likelihood of that to happen, by monitoring the incoming betas. The higher the number of the current beta, the closer it's to the GM (gold master) release, after which all bets are off.
In other instances, changes in the platform may rattle some dormant bugs already present in the app. Those bugs are the developer's responsibility. The good thing is that with that responsibility comes power and control too. That is, a competent developer should be able to fix them. That's opposed to the previous scenario, where you're entirely at Apple's mercy, to fix their mess, unless you have a developer that can come up with a workaround. If you work with a less gifted developer, your option is to find a second opinion, or, if the problem hasn't been fixed in time before the release that introduced the breakage, enlist the help from Apple DTS (Developer Technical Support). You get 2 free support incidents per year with your membership in their developer program, and you can purchase more at a low cost. I never had to use that myself, so I couldn't comment more on that.
So there you have it, a rundown of the issues that may crop up post-release. On all my projects I offer my clients a maintenance plan that charges a monthly fee to test the app on the latest beta and to handle any issues encountered. So they can have the piece of mind knowing that their initial investment is protected.
Posts
