Join 3,363 readers in helping fund MetaFilter (Hide)


iPad, you say? Looks like a little teevee to me, sonny.
July 15, 2011 11:28 AM   Subscribe

My next task at work is to turn one of our existing web applications into an iPad app. Help me get to the point where I know where to start.

So I've never owned an Apple product, although I've been a programmer and web developer of various kinds for 20 years. I don't think I've ever actually seen an iPhone close up, let alone an iPad, and the last time I used a Mac it was running System 7. I'm by no means out of touch with the world; I just don't live or work in an Apple-centric environment. All of which is to say, please excuse my obvious ignorance.

I've been tasked with converting a couple of parts of a (LAMP) web app into one or more dedicated iPad apps (maybe a universal app that'll also work on an iPhone). I understand that to do serious development work I'll need an iPad, a Mac (a mini or a macbook seem to be the cheapest options) and a signup for the developer program. So far so easy.

My first real hurdle, I suspect, is finding the right development platform. My background includes things like Visual Basic, which then led to all kinds of web stuff (ColdFusion, Javascript, ASP, PHP and Flash). I take to new languages like a duck to water, usually. Given this background, what development strategy is going to suit me best? Note that the result must be a fully-fledged 'app', and preferably not something browser-based or running on top of something else that needs installing or carries its own branding. The iPad app will essentially be an alternate front-end to the web app.

My second point of confusion is about getting to grips with app distribution. This will be an app that is given to couple of hundred existing customers as a 'free' extra on top of their web app subscription, and will only be relevant to them. The wider world has no need to be aware of it. The process for getting the app needs to be as straightforward as following a link in an email. What's the best way to reconcile these requirements with Apple's various distribution channels?

I realise that it might seem illogical to specifically want an app when there's already a perfectly usable web version of the same thing; but logic often loses out against fashion and the enthusiasm of big boys for shiny toys.
posted by le morte de bea arthur to Computers & Internet (18 answers total) 14 users marked this as a favorite
 
Have you considered making an iPad-optimized website instead? JQuery Mobile is perfect for that sort of thing.
posted by blue_beetle at 11:32 AM on July 15, 2011


My second point of confusion is about getting to grips with app distribution. This will be an app that is given to couple of hundred existing customers as a 'free' extra on top of their web app subscription, and will only be relevant to them. The wider world has no need to be aware of it. The process for getting the app needs to be as straightforward as following a link in an email. What's the best way to reconcile these requirements with Apple's various distribution channels?

There are plenty of apps in the app store that are only relevant to people who pay for a service outside of iTunes - for example, HBO Go, which is only useful if you have HBO on your TV, or the various apps that do things like unlocking your car for you. You can easily provide your users with a download link that will take them to the relevant page in the store, and let them download your app. The wider world will be able to find it, if they look for it, but if you're not promoting it to them, chances are they'll never see it.

blue_beetle: Have you considered making an iPad-optimized website instead? JQuery Mobile is perfect for that sort of thing.

I suspect, based on the last line, that le morte's employers have commanded "thou shalt create an iPad App!" and the fact that it isn't actually the best way to do this is kind of beside the point.
posted by Tomorrowful at 11:37 AM on July 15, 2011


Tomorrowful, I did consider the straightforward App Store option, but it seems a really odd thing to do given that this app is basically a private thing. In some ways the Enterprise Program looks closer to what we want, although it seems costly and doesn't seem geared to distributing apps to clients rather than employees.
posted by le morte de bea arthur at 11:54 AM on July 15, 2011


As I understand it, your app can basically just be a wrapper for a web view. Maybe you have an alternate stylesheet, some touch-friendly JS, and that's it? Does the app need to work when they don't have web access?
posted by misterbrandt at 11:56 AM on July 15, 2011


If you want a truly native iPad app, your best (and AFAIK only) language choice is Objective C, usually used along with XCode, Apple's IDE. I've found it sufficiently different from standard web coding that I'd recommend working through a book or two. From your list of languages, memory management might be a new thing that you should pay special attention to.

In terms of distribution, I tend to agree with Tomorrowful. There's no easy way to get apps on a device without using the app store. Apple does have an enterprise program (with associated licensing) that allows you to distribute apps in-house to employees, but what you're describing sounds like customer distribution. (On preview, it looks like you've come to the same conclusion about the enterprise program.)

Developing for iOS is fun, but there's a steep learning curve due to the technical challenges and the ecosystem. There's a reason experienced mobile app developers can command a high rate right now - there's a lot to learn, and the frameworks that we take for granted in the web world generally don't exist yet for mobile apps.
posted by flipper at 11:58 AM on July 15, 2011


I'd recommend jQuery Mobile or Sencha Touch, then PhoneGap - this will let you convert a web app into a "native" app.
posted by me & my monkey at 12:01 PM on July 15, 2011


Apparently Adobe is coming out with an IDE that will allow you to build apps that run on all mobile devices...
posted by toastchee at 12:05 PM on July 15, 2011


Tomorrowful, I did consider the straightforward App Store option, but it seems a really odd thing to do given that this app is basically a private thing.

Oh, I heartily agree. But that is how things tend to work. Some examples:

* A BMW Roadside Assistance app that only "works" if you have an in-warranty BMW

* The Sonos Controller, which is only relevant if you own a Sonos system to use it with

* The Parrot AR.Drone is controlled by an iPhone app that anyone can download, but will be really boring if you don't own a Parrot.

...and soforth. Apple really doesn't want non-iTunes methods of distributing apps; there's the Enterprise system, but it's specifically suited only to distribution within an organization. If you want to get stuff out to the public, even if it's useless to 99% of them, sticking it on the App Store and providing a link to download it is the way to go.
posted by Tomorrowful at 12:19 PM on July 15, 2011


I'd recommend jQuery Mobile or Sencha Touch, then PhoneGap - this will let you convert a web app into a "native" app.

You need to read this part of the post:

Note that the result must be a fully-fledged 'app', and preferably not something browser-based or running on top of something else that needs installing or carries its own branding. The iPad app will essentially be an alternate front-end to the web app.

The requirement is for a native app. The best way to go about this from the noob perspective is to start building out an API from your legacy app and either employ a firm that specializes in iOS development to build and submit the app for you or like you said, go through a couple of books. If you have more time than money and the patience to dig into Objective-C, then choose the later over the former. Avoid wrapper apps at all costs; you go either native or HTML5 app. Google+ is a great example of what can be built for a mobile browser but they have ~200 engineers on the team writing Closure from servlets.

So I've never owned an Apple product

You'll need a OS X system to host xTools and the included testbeds. For slightly more money you'll need at least an iPhone 3GS and a first-version iPad to ensure that your project actually works IRL prior to submitting it to the app store.
posted by jsavimbi at 12:21 PM on July 15, 2011


I have developed/distributed under the Enterprise system; as of about a year ago the licensing not only specified that it must be internal to the organization, but that the app could ONLY be used by employees of the organization and ONLY be installed on devices actually owned by the organization. I'm not sure if that is actually enforced in practice, but in general that's a deal-killer for almost any app. Most people own their own iPhones/iPads and just use them at work. My app was installed on just a few devices that were bought specifically for the project.

The Apple app store is the appropriate way to distribute this app even if it's only of use to very specific customers.
posted by pekala at 12:40 PM on July 15, 2011


You could write your web app to be a RESTful web service. Your iOS app will be a REST client that issues a web request to the web service. The service issues a response in JSON, XML or some other serialized form. Your app parses the response and updates its internal data model, after which the custom UI gets updated. Rinse and repeat.

You'll need an Intel Mac, preferably one with an Intel Core Duo 2 or better so that you can run Lion. (Why? Because Apple will invariably update their Xcode development suite and running Lion will one day, not today, be a requirement.) You will run Xcode on this machine, which includes a simulator to run and test apps, as well as the IDE to do coding, compilers, leak and performance utilities. Some people argue that the simulator does not do a correct job of fully replicating the iOS device experience, and this is true. However, unless you are writing an OpenGL game or audio synthesizer, or otherwise making heavy use of hardware resources, you'll almost certainly be fine testing your app on the simulator. You can get an iOS device to polish your app UI at the end of the development process.

Native apps are written in Objective C and will give the best, fastest and most consistent user experience on iOS devices. That's just a fact, because PhoneGap etc. are always in between your client and server. You can also code in C and C++, as well as include static libraries that are written in those three languages. This opens up a massive amount of functionality in the form of open source projects like ASIHTTPRequest, TouchJSON and others.

Distributing your app through the app store is fine. Most apps languish in obscurity, anyway, so unless your app is a top download, most won't even know it exists. There are just so many apps on the app store. Have a good, strong authentication/authorization method in place, and you'll be fine. The Enterprise program is for companies with more than 500 employees, which have registered DUNS numbers, so unless you plan to host your own apps and this scenario applies to you, just use the regular app store. You can provide a link to your app that can be opened in an email. Clicking the link will then open iTunes, and then open the app store to load your app page. People then install your app as they would any other.
posted by Blazecock Pileon at 1:03 PM on July 15, 2011


What threw me off with Objective was their function naming convention.

(int) adder:(int)firstArg withSecondArg:(int)secondArg

is viewed as
int adderWithSecondArg(int firstArg, int secondArg)
in a traditional language.

an adder with three arguments in the Objective C style would defined as
(int) adder:(int)firstArg withSecondArg:(int)secondArg withThirdArg:(int)thirdArg

is viewed as
int adderWithSecondArgWithThirdArg(int firstArg, int secondArg, int thirdArg)

Objective C does not have garbage collection. There's a recommended style to allocating and managing objects recommended by Big nerd Ranch, but you still have to read APIs to figure out if the called function handles the memory management of the object or if you're responsible.

I would recommend programming the application natively. You get access to all the hardware features of the iPhone without the pain of going through the browser. I didn't like interacting with the browser to access GPS coordinates.

Also make sure you know what platforms you're programming for. iOS 4 introduced lambdas (anonymous functions), but they won't be used for a while as every developer wants to support older iPhones and iPod Touches.

Understand the MVC paradigm. It's not that hard. Basically, views and models lent themselves to object oriented paradigms, while controllers (the brains and logic of the application) did not. UIViewControllers are used to manage data objects you have and GUI objects you have. You should really only have one UIViewController per screen. ViewControllers manage the screen contents.
posted by DetriusXii at 1:13 PM on July 15, 2011 [1 favorite]


What threw me off with Objective was their function naming convention

The roots of Objective-C's syntax in this regard can be traced back to Smalltalk. It's what makes the language (largely) self-documenting. It's peachy.

For what it's worth, you're not calling a function with a list of parameters, you're sending a message to a receiver. Or, you just say you're invoking a method. It's like a method on a object in other languages, except with futuristic-looking brackets. (Remember, Objective-C predates Python, Java, Ruby, JavaScript, etc.)

As far as the brackets go, you'll have to ask Brad Cox, the inventor of Objective-C, why that syntax design was chosen. Perhaps it was to formalize the message send construct, perhaps it was to make the original Objective-C preprocessor work correctly, or perhaps it was simply a stylistic decision. Some combination? I've got no idea.



SO YOU WANT TO KNOW HOW OBJECTIVE-C MESSAGES WORK AND WHY THEY'RE SPECIAL

Okay, if you don't, skip down. Otherwise, here's me plagarizing myself from elsewhere:

Objective-C is a highly dynamic language. There is a construct in it known as a selector. It's called that because it allows the runtime to select the code to execute; the method that will be called when the program runs is not determined until runtime.

You send a message to a receiver (usually referred to as "invoking a method") like so:

[myObj setValue:@"foo" forKey:@"bar"];

At compile time, this gets converted into a call to a function named objc_msgSend. The arguments to the call include the object itself, the selector name, and all of the arguments you provided. The function looks like this:

id objc_msgSend(id theReceiver, SEL theSelector, ...)

In the example, the selector name is the fully qualified string "setValue:ForKey:", colons included. (Selectors actually have a special type once compiled, but these details aren't important here.) The code generated by the compiler is equivalent to (for our purposes here):

objc_msgSend(myObj, @selector(setValue:forKey:), @"foo", @"bar");

At runtime, objc_msgSend resolves the selector to a method implementation, which is the actual function for the resolved method that should be invoked. This is a C type known as IMP:

id (*IMP)(id, SEL, ...)

An IMP is a pointer to the actual function that implements the method. Its arguments are the same as objc_msgSend.

If you want to know why it works this way, think about how one might implement message forwarding (an object receiving a message to which it can't or doesn't want to respond, and subsequently sending that message to another object) and reflection (type and capability introspection performed at runtime).



Objective C does not have garbage collection.

Well, it does, but not on embedded devices where performance is critical. It exists in Mac OS X, but not iOS.

There's a recommended style to allocating and managing objects recommended by Big nerd Ranch, but you still have to read APIs to figure out if the called function handles the memory management of the object or if you're responsible.

There are clearly defined naming conventions for Objective-C methods and Core Foundation-style functions that describe the object ownership contract from the caller's perspective. I won't summarize them here. Here are the guides:

Cocoa Memory Management Guide (iOS)
Memory Management Guide for Core Foundation

These rules don't apply to absolutely everything one can encounter in iOS and Mac OS X (e.g., syscalls at the POSIX layer). But they're the convention used throughout AppKit/UIKit, Foundation, CoreImage, and many other APIs. Knowing the rules gets you a very, very long way.
posted by Mikey-San at 7:02 PM on July 15, 2011


A few more Apple Developer Connection guides you should know about:

Learning Objective-C: A Primer
Your First iOS Application (a tutorial document)
The Objective-C Programming Language (this is a big document, use it as a language reference)
posted by Mikey-San at 7:54 PM on July 15, 2011 [1 favorite]


Ah ha! From an interview with Brad Cox:
"Quite literally [the use of brackets] was a search for something that wasn't taken. Curly braces were taken. Ordinary parentheses were taken. It was just a search for braces that wouldn't collide with something C used."

posted by Mikey-San at 8:05 PM on July 15, 2011 [1 favorite]


Thanks for the responses so far. I feel like I'm getting some idea of what it'll take to get started writinga native app.

Suppose I want to widen my criteria slightly and include non-native development (I probably shouldn't have been quite so dismissive). This app won't be doing anything that requires high levels of graphics performance (in the main it's just form-filling and display of static text+graphics documents). Again, pardon my ignorance, but can non-native apps be packaged and distributed in ways that make them indistinguishable from native apps? If so, what SDKs/platforms are worth consideration. Are things like Corona, Sencha Touch, PhoneGap and all the others actually viable alternatives to diving in to Objective-C?
posted by le morte de bea arthur at 11:52 PM on July 15, 2011


Yeah, if you're just building forms and simple display, I think that PhoneGap is definitely a viable alternative (and to jsavimbi above, a lot of times managers/customers want a "native app" but that just means to them "something that they don't launch from the browser").
posted by me & my monkey at 7:51 AM on July 16, 2011


I'm currently developing using Rhomobile and Grails because these are the technologies used by our student information system vendor, Sungard, in their Mobile Connection software. We'll be releasing our apps soon. After some initial learning-curve issues, I've come to like both Rhomobile and Grails. I may graduate to native development one day but for now I can do what needs to be done.

The Grails/server side takes the REST approach advocated above.

We're currently only using Rhomobile and none of the other Rho* products. RhoGallery, as I understand it, can handle this requirement: "The process for getting the app needs to be as straightforward as following a link in an email. What's the best way to reconcile these requirements with Apple's various distribution channels?" I believe this is handled by getting an Apple Enterprise Certificate which allows you to distribute apps through RhoGallery but you can still put your app in the iTunes store if you wish. Please double-check all of this as my focus has been mainly on Android (I'm moving to the Apple side soon).

You can find great Grails developer documentation anywhere but the Rhomobile developer documentation is not nearly as satisfying.

Here are some links:

http://rhomobile.com/

http://groups.google.com/group/rhomobile

http://grails.org/

https://github.com/rhomobile
posted by loosemouth at 8:02 AM on July 20, 2011


« Older What is it like editing a lite...   |  What's the best knitting app f... Newer »
This thread is closed to new comments.