iPhone

10 things you need to know about iPad and iPhone development

If you're getting ready to jump into iOS development, these practical insights will help you get started.

With the iPad's domination of the tablet space and the iPhone continuing to enjoy strong sales, interest in development for these two platforms keeps growing. I have started getting my head into the iOS development game. These are 10 things I have learned about developing for iPads and iPhones along the way.

1: You need a Mac

It may sound like a conspiracy theory to get folks to buy Macs, but without a Mac you won't be able to get your application onto a device for testing. And you need to be testing on a device.

2: You really should get an iPad and an iPhone or iPod Touch

Yes, there is a simulator. But the truth is, simulators only go so far in replicating the experience a user will have. In my experience with mobile application development, even "simple" applications can be a joy to use in the simulator and a hassle on an actual device. And since you'll likely want your application to work well both for iPhone/iPod Touch and iPad, you will want to get an iPad and either an iPhone or an iPod Touch (the two are identical as far as development is concerned).

3: Objective-C is a bit of a throwback

My first reaction at looking at Objective-C was, "Wow, that looks like the stuff I cut my teeth on!" And I was right. While Objective-C supports modern programming elements like object-oriented code, it is a fairly low-level language, too, and it clearly has not strayed too far from C. For example, you need to prototype functions in a .h file. It reminds me in many ways of the Delphi system in that regard.

4: XCode is radically different from Eclipse and Visual Studio

Coming from the Visual Studio system, with a couple of minor detours into Eclipse, I found XCode to be a bit jarring. The focus is really less on everything that happens in the toolbars, sidebars, and menus, and more on what happens in the middle of the screen, which is writing code as text. This isn't to say that XCode isn't visual or that it lacks tools. But the overall system simply has a different philosophy from the kitchen sink approach that Eclipse and Visual Studio take.

5: XCode is ready to work with Subversion or Git

Out of the box, XCode comes equipped to work with Subversion or Git. You are still free to use any other source control system you want (through command-line tools, if they don't have a GUI system or XCode integration). But if you already use Subversion or Git, you will be happy.

6: You should sign up for your developer account early

It can take up to two weeks for your developer account to be approved. The sooner you sign up, the sooner you will be able to get your app deployed to your test devices or uploaded to the App Store for approval.

7: There are different types of developer accounts

Developer accounts come in three major flavors: individual, company/organization, and enterprise. The main difference between individual and company/organization is that the latter allows you to create users within the account who can access it. Individual accounts are limited to a single user. Enterprise accounts are an entirely different beast: They allow for private deployments, which is exactly what an IT department writing apps for internal use needs. There is also an academic account for students, which allows some access to the developer program.

8: You can write code without a developer account

The good news is, if you are just learning, and are willing to forego deployment to a test device or putting your app in the App Store, you can use XCode and the iOS simulator without a developer account. The developer account has lots of benefits, including early access to betas and such, but for learning purposes, no account is needed.

9: iPads are not just big iPhones

When designing UIs, it's tempting to think that iPads are just large iPhones. While this is more or less true at a code level (apps that run on iPhone will run on the iPad, though iPad-specific apps will not run on iPhone), it is a big mistake for designing the UI. An iPad's bigger screen allows you to pack a lot more information on the screen without overwhelming the user, and the larger screen size will affect what kinds of UI widgets can be comfortably used.

10: There are alternatives to Objective-C and XCode

If, for whatever reason, you do not want to work with Objective-C and XCode, that is just fine. A wide variety of other options are available for iPad and iPhone development work. You can run C in MonoTouch or use HTML and JavaScript in Titanium (or a number of other systems) --  and those are just two of the more well-known options. Once you stop working in Objective-C, you do not need to be using XCode, either.

About

Justin James is the Lead Architect for Conigent.

20 comments
ektacis
ektacis

Thanks for sharing such a wonderful information on what to keep in mind and should know about iPhones and iPads. Quite useful stuff!!

BitHammer
BitHammer

The stuff I cut my teeth on was C and C++. So far, as cryptic as those languages were, I've found Objective C far worse. What's with all the square brackets around method calls, and dashes and parentheses for method definitions? Isn't the objective of creating a new language to make the language better? Epic Fail!!! Sorry, just a little frustrated. I'm trying to do fairly simple stuff and being thwarted at every turn by a language whose objective seems to be obfuscation.

kirk_augustin
kirk_augustin

You wrote, "you need to prototype functions in a .h file", as if that is a bad thing? It isn't. That is the way all languages should handle prototypes. The reason is that anyone interfacing with the object needs to have the prototypes during compile time, in order to ensure run time compatibility.

shane van
shane van

There was a mention already about Firemonkey but most people have probably never heard of it. Borland pascal became Delphi which then was sold to Embarcadero and is now really being developed and supported. Last year they released "Firemonkey" which can be programmed in either Delphi (pascal) or C. Firemonkey allows you to write one app and then compile it for Windows 32bit, Windows 64bit, iOS, and (with a bit of effort) Android. But you also get an IDE that left Visual Studio far behind for years, a huge range of additional controls, and a platform that avoids the OS where possible and talks directly to the graphics cards. My only word of caution is that this is still a real programming language. It isn't one of those cookie-cutter app builders.

333239
333239

I've not tried it, but there is also Embarcadero FireMonkey which can be used to develop cross platform for iOS as well as Windows and Mac in Delphi or C++.

rufwork
rufwork

I'm assuming the CMS stripped the pound, but that's "If, for whatever reason, you do not want to work with Objective-C and XCode... You can run C# [C-sharp] in MonoTouch..." Mono is surprisingly impressive, btw. I've been using it to develop console apps while I'm away from Windows, but its Windows.Forms support (not design, just the ability to run) and especially its ASP.NET support is surprisingly good.

catalyst_ts-24707775057625554655047630547595
catalyst_ts-24707775057625554655047630547595

Fine list. I would also mention the horrible app signing procedure. You have to jump through several hoops before you can run your program on a test device or send it to the app store. On the other hand there is a big development community helping you out. We at www.catalysts.cc always try to get things running ASAP. Without the community starting app development wouldn't have lasted days but weeks.

Kriskret
Kriskret

Very soon you will buy bag of sugar at grocery store with the logo on it :- i-Sugar. Hey...guys from Macintosh .... ! Did you forget ? - There are plenty of devices much better then your i-junks. There are :HTC, Samsung, Nokia Lumia - they are O.K and getting better. Certainly, mentioned before (ironically) the conspiracy exists. - How do you explain that other companies have tailored their's hardware and software to i-Phones or/and i-Pads only. Do you want a list ?- MagicJack, PalTalk and tens of others. Still, we're waiting for decent Windows Mobile smartphone or other operating system device (but for sure not any of i-junks) and will buy it !!!

jsargent
jsargent

"For example, you need to prototype functions in a .h file. It reminds me in many ways of the Delphi system in that regard." Errrrrmm...actually nothing like Delphi. What exactly do you mean? I'm not sure how many developers will agree with you there.

Werner de Jong
Werner de Jong

Hi Justin, Indeed a nice list but what you forgot to mention is the large amount of code examples and development frameworks free to use for all like Cocos2d (box2d which is used for Angry Birds) As well as many easy to use tools (which I wont mention as they are not free but easy to trace and cheap) for optimizing image use and memory usage.

Justin James
Justin James

Under the hood, Objective-C is basically a metric ton of macros that translate all of those goofy Objective-C quirks into standard C. So the parts that are Objective-C HAVE TO stick out like a sore thumb for the compiler to pick them them. Also, you don't *need* to use the square brackets, you can use dot notation. Apparently, the Objective-C folks like to have wars on the level of "Great Taste!" vs "Less Filling!" on the matter of dots vs. brackets... :D J.Ja

Justin James
Justin James

"The reason is that anyone interfacing with the object needs to have the prototypes during compile time, in order to ensure run time compatibility." Other static, strongly typed languages manage to handle it fine without prototypes. I see prototypes as an artifact of challenges in compiler design that were solved after the solution of prototypes was introduced. Dealing with prototypes is a hassle, because you need to constantly keep them in sync with the implementation, or have a tool to do it for you. And if the tool is constantly syncing them, then why are they needed in the first place? J.Ja

Justin James
Justin James

... but I haven't had the time to take a look at it. Embarcadero keeps me in the loop on their stuff, and has been very easy to work with, makes themselves available to me for looks at their products, etc. Firemonkey is on my list of things I would love to try if I had the time. Maybe after my forthcoming Rails experiments? J.Ja

steamIngenious
steamIngenious

Negative votes for your blind and ignorant evangelism. Computers are tools buddy, try not to be one yourself.

Justin James
Justin James

... it had an "interface" block to prototype all functions and was similar in that regard. It's been a while, but a quick check shows that this hasn't changed from what I can tell. J.Ja

Mike Page
Mike Page

For a strong statically typed language to know a function or class signature the compiler must read and parse it. Header files allow client code to have access to those definitions without having access to the implementation keeping the application's physical coupling low. This allows the implementation to change without the client code needing to be recompiled (providing the signature has not changed). In small applications this is not a big deal, but in large applications a change could require a lot of code to be recompiled due to header inclusion dependencies. Keeping headers in sync with the implementations is a piece of cake. If you screw up the compiler tells you immediately and you fix it. In practice this type of error rarely happens. A great thing about header files is that they allow you to create a declaration from a class that is separate from the implementation. This makes the class structure much more clear than in languages that mix the declaration and implementation together (ex: Java).

jsargent
jsargent

Sorry. When you started comparing .h files with pascal object declarations it was a little confusing. Moving on though, for pascal fans I would suggest Lazarus. It's really taking off and rapidly expanding its platform portfolio and is also able to develop applications on the Mac.

Justin James
Justin James

... the weakness of using plain text files to represent code. It's a model that was outdated 10 if not 20 years ago, and it holds us back as an industry. From top to bottom, software development would be substantially improved by a shift to a richer file format. For example, make exception handling a form of meta data that can be applied and re-applied to code as needed instead of inline code. There are systems out there that do this stuff, and they are fantastic. J.Ja

Justin James
Justin James

It's my fault, sorry! I should have been a bit more clear. :) I've looked a bit at Lazarus in the past. Pascal was my first true love as a programming language... as a freshman in college, I actually used my credit card to buy an academic version of Delphi 1 for $99, even though I could have easily procured a... um... less than "legit" copy of it. For a college kid to drop $99 on a programming system instead of the usual college pursuits shows how I felt about Pascal. :D J.Ja

steamIngenious
steamIngenious

Thanks for this! I loved Pascal in high school and wrote many programs in it, including a 3d engine (on a monochrome monitor! haha) and an interpreter. Will definitely look at Lazarus!

Editor's Picks