Macworld Forums: Diary of an App Maker: What it's like to develop for iOS - Macworld Forums

Post your comments for Diary of an App Maker: What it's like to develop for iOS here

Finally, a good article about being an iOS Developer!
I'm one myself, so I know what you're talking about.
Thanks guys!

Very good article. I'm not a developer, but I appreciate your pain. Rather than me blather about how I think it could be better, what are your thoughts on how the iOS ecosystem could be better for developers?

Yes, it's nice to hear from an actual developer. I haven't used in app purchasing, but I do know that getting your app to testers can be tricky. Hopefully there is some progress announced at WWDC!

I'd love to see an article that goes in depth on the actual app development process. IOW, what's actually involved in designing and building an app.

"Building Let’s Sing was tough—especially given that we both have other full-time day jobs."

I'd love to see a deeper discussion of this aspect all by itself. Were you only juggling your day job and this work, or do you also have families / significant others that need your time and attention? What sacrifices were made to get this app out the door (besides the obvious "sleep!")?

Did you decide that personal sanity and some semblance of occassional "down time" was more important than rapid app turnaround? Or did you feel it made more sense to just bang out the app so you stayed focused?

These are all issues and questions I'm struggling with as I try to get some kind of app development going while juggling my day job and the needs of my family (including two young and very talented daughters).

klahanas, on 24 May 2012 - 05:57 AM, said:

I think Apple could work to make testing easier. Easier to get users copies of the app to test, easier to get error reports, easier to test in-app purchases, without too much effort on Apple's part.

On the ecosystem at large, that's a bigger question, and I'm not sure I can fit my answer in a comment

aralim_1, on 24 May 2012 - 06:19 AM, said:

Great questions.

I have three kids aged five and under. Marco has two kids, too. I gave the app some of my night and weekend attention. On weekdays, I only worked on it after my kids were in bed. On weekends, I did devote a few hours during the day, when I could have been spending family time, to the app. My thought was that perhaps the app could benefit the family long term, so it was an acceptable sacrifice to make.

We did keep personal sanity paramount. That's not to say there weren't late nights and periods of frustration while we worked towards completion. But though we missed the first date we'd set for ourselves to release the app, we were comfortable taking the time needed, and not simply squeezing 50 hours out of each day.

Some of this is a bit exaggerated.

Quote

Xcode nowadays automatically bundles the provisioning profile inside the app package it generated for ad-hoc distribution, no manual installation necessary.

Quote

You don't wait until the app is actually live, the ad-hoc distribution version you gave to your testers already had to use the production push notification server.

Thanks for the article, I'm in about the same boat as you are, though not as far along. I'm interested in the process of creating the app. How much prototyping did you do before creating the app? And how much marketing did you do and what kind?

I should also add that, like you, I am writing about the process of creating an app. I blog about it at http://www.limulussystems.com/blog/. I know, it's a shameless plug.

Sorry to hear that you didn't get better reviews!

I have developed several android apps, and it is no easier. I thank you for publishing this, as it gives a good insight into the actual issues associated with app development.

"but once your app is actually live, those notficiations need to use a different server--with a different certificate. So you can't actually verify that your push notifications will work with the real live app until you yourself can get the app from the App Store."

Not true. Use the production server, and send the notifications only to your own devices.

The problem I have with this review is the condemning of Apple for their certificate handling between different accounts. While the process might be difficult to deal with, blaming Apple demonstrates an ignorance of how certificates and public key infrastructures (PKI) work.

In short, certificates are issued and bounded to a single entity. If you have a test app that is using a test system, you have one certificate bound to your test app that identifies it as a test app that is bound to a server that has its own certificate. When you move from being a test app to beta, your type and security requirements change, which has to be recorded in the certificate.

Once you have to change the certificate, it has to be reissued. The certificate, which is defined by the ITU-T X.509 standard, is digitally signed after it is created. If you change the certificate in order to change elements within the certificate, you will break the signature (it will not verify) and invalidate the cert. The only way to change a certificate is to reissue it with the new information and digitally sign it.

The same with the app store. The app store is a different entity and has its own certificate for identification. To interact with that entity, it needs its own credentials that required another certificate.

To ask Apple to use the same certificate for testing and production would add a unnecessary risk to their infrastructure. Regardless of what developers think (and I used to be a developer before moving into security), you should NEVER be testing on production systems to ensure its integrity. Requiring two different servers with two different certificates is the absolute right way to configure the system.

These are NOT limitations of what Apple is doing but the limitations of PKI. PKI requires the one-to-one entity relationship between two communicating entities.  The separation between the systems requiring different certificates is the proper way to reduce the risk to the integrity of the production system.

For more than 10 years, PKI proponents have decried every year as "the year of PKI." But PKI is difficult because of the "I," the infrastructure. The infrastructure, from the servers to the certificates, is not easy and it is not easy to make it so that it works without issue for the end user. Apple's tradeoff was to make it difficult on the developer in order to preserve the user's experience.

Security may not be your forte, but just as you would decry someone learn the nuances of programming for iOS, if you are going to use, program, and (most importantly) publicly comment on PKI and security issues, you should educate yourself before doing so.

I wanted to submit my Mac app, SideEffects (http://macmatrix.blo...ideeffects.html), to the App Store but Apple wanted to charge me $99 for hosting a free app. It leaves a bad taste when the world's biggest company is also the only one charging for access. My App is listed with MacUpdate, Softpedia and Bodega - none of whom even vaguely want anything from you. They all have a submission process with quality standards.

Until I came up against that particular hurdle I was wondering whether an app like mine would get past the review process seeing as it hacks an element that Apple appears to have gone to lengths to secure: the Sidebar colors in Lion. That point is now a moot one, however it got me into wondering: will the day come when Apple will only allow certified apps onto the platform, closing Gatekeeper's gates, so to speak.