Discussion on:

10 things you need to know about iPad and iPhone development

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.

"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.

... 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

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.

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!

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.

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.

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++.

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.

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.

"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

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).

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.

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