Keith Tingle's presentation notes from March's Meeting

1. Hi everyone thanks for coming, its great to be back at ArcSig. Normally I present on .NET
topics, but this last year has been unusual year for me.. I got involved with several
enterprise and B2B iPad projects. There are some challenges, some pitfalls associated with
iPad development and if any of you find yourself working on or around an iPad project my
hope would be that this talk helps you avoid some of those pitfalls.
Apple has targeted the consumer and education markets with the iPad, I don’t think there
is any question about that; but what about businesses? Can businesses repurpose the iPad
as a tool to do real work? I think so. Do people just want to bring their favorite toy to
work? I believe that also. I have encountered some customers who simply had to have an
iPad app. Some business people feel that there is some sort of technology phenomena
going on and they are compelled to participate. They charge down the path of creating an
iPad application for their business thinking that it’s going to be a relatively small or simple
project. After all the device is small and its simple to use, so its somehow intuitive that
creating software for it is easy. The truth of course is that its no simpler to create software
for the iPad than it is for the web or the desktop. In fact depending on your project
requirements you may find the platform to be *more* challenging to develop for than
some of the conventional platforms like .NET and Java.
As architects and developers our goal is make our customer’s vision come to reality;
whether Apple targets business users or not. We have an obligation to make it work.
1

2. So before we start writing a single line of code we have some big choices to make. None
bigger than what style of application to write.
You have two choices, a native iOS application or an HTML 5 web application. Sometimes
the requirements make this choice for you, sometimes your customer is adamant about
their choice and your path is set.
My hope is that business people will always consult the technical experts to help make
these kinds of important choices. We need to make sure on our end that we understand
the options fully and that we lay them out clearly before the project gets started.
I have put together some key questions that I think help choose the correct path for a given
project.
• I have encountered some apps that are functional clones of web sites. The app offers
more or less the same user experience as the web site.
• Are your users employees of the same company where you work? or are you in a B2B
situation where you are creating tools for your customers to do business? This is a
crucial question… and we will talk about why its so important when we talk about
deploying native iOS applications.
• Can your users wait a week for a fix to be pushed through the App Store approval
2

3. process? What happens if the app is rejected for some reason? Is this going to impact the
business somehow?
• Does your QA team use automated tools to test your software? Do they have processes
already in place for testing web applications? If QA is an afterthought in the planning
stages of the project is going then its probably going to become a critical issue towards
the end of the project where QA is most active.
2

4. The first thing you need to get started with iOS development is a Mac with OS X. You must
use Apple hardware to legally create iOS software.
Normally if we need to develop software in a environment that is not a conventional
desktop environment.., our IT folks will ask us to use virtualization. So historically Apple has
restricted virtualization of the client version of OS X. The story got a little bit better with
the release of Lion, the most recent version of OS X. You can legally run two virtual
instances of Lion locally using a virtualization product like VMware Fusion, but you are still
limited to Apple hardware. You are not going to be able to install VMware workstation for
Windows and install a copy of Lion as a guest O/S.
I have seen a lot of terminal server solutions on the web for delivering OS X desktops to
users but I have no experience with those solutions so I cannot really vouch for their
effectiveness for development purposes. I assume your developers would be able to test
their code on the iOS simulator in a terminal, but in order to debug on a real iPad they
would need an Apple computer with a USB port to plug the device into. Testers do *not*
need Macs, but of course they need an iPad to download the software and test it.
For most companies I don’t think it’s a huge issue to get everyone on the team a Mac, it’s a
good morale booster certainly but its something you need to plan for and budget for.
Xcode is the Apple supported IDE for iOS and OS X development. It’s a free download from
the Mac App Store but it does require Lion. I think there are older versions also available
3

5. that will run on Snow Leopard, I am not sure if those versions are also free or not. There
used to be a $5 charge for Xcode on the App Store.
If you intend to run your apps on real devices you must enroll in the iOS Developer Program.
This gives you access to some developer forums and other resources but the real reason you
join is you get access to the provisioning portal. The provisioning portal allows you to request
development & distribution certificates, reserve App IDs, and create provisioning profiles.
You also get access to iTunes Connect which is the developer gateway for uploading apps to
the App Store.
The iOS Developer Enterprise Program (a.k.a. IDEP) allows you to build in house enterprise
apps and deploy those apps outside of the App Store. We will cover this in depth later.
3

6. iOS apps are typically written in Objective-C. Objective-C extends C with some additional
keywords that open up an object oriented style of programming. Xcode also supports
Objective-C++ which is a Frankenstein language that tolerates Objective-C and C++
constructs in the same application. There are many restrictions.., for instance you cannot
derive one type in one language in the other language. Objective-C++ is useful for multi-
platform programming, for instance if you wanted to share a library between iOS and
Android, you could compile the same code with both Xcode and the Android NDK. I am not
sure what the C++ support is like in WinRT but I assume its possible to compile ANSII there
as well. That’s pretty compelling that you could share core logic between three mobile
platforms with a shared C codebase. I am currently working on a project where we smooth
stream Microsoft PlayReady DRM protected content to an iOS player. << Explain Microsoft
PlayReady client licensing w/ regard to ANSII C>>
You create type definitions in Objective-C in a dot h header file like C++. Objective C
implementation files are given a DOT-M file extension, and Objective-C++ implementation
files have a DOT-MM extension.
4

7. The analogy with C+ was useful to me in the early stages of learning the language; but
Objective-C is a very different language that just shares some heritage w/ C++. One large
difference is that all method calls in Objective-C are dynamic. You can send any message to
any object, the compiler will emit a warning if the receiving type doesn’t declare support
for that message.., but it won’t break the build. Every message is represented by the
compiler as a selector, all instance methods are ultimately passed the self and parameter
and a selector parameter that identifies the message that was sent to the object. The
compiler supports a specific syntax for selectors.
I am sure this is a powerful feature of the language but it seems underutilized to me. I have
not encountered developers using the dynamic features of Objective-C as often as I have
seen them used in JavaScript or Ruby.
There is a garbage collector available for OS X applications, but not for iOS. I think iOS is the
only mobile platform (maybe Symbain?) that doesn’t have a garbage collector. iOS 5
introduced Automatic Reference Counting or ARC. Its eases the load of low level memory
management for developers but it is not a fully fledged garbage collector. It’s a build
setting.., and it requires the developer to stop managing memory in their code and
delegate that responsibility to the compiler. The compiler with emit errors if the developer
attempts to manage memory manually. So it’s really an all or nothing proposition. If you
have legacy iOS code you have to do more than just compile with ARC enabled, you have to
remove the memory management portions of your code base. Xcode ships with a
refactoring tool that will assist with this conversion.
5

8. Blocks are a C-level feature added by Apple. They are closures and they were introduced to
facilitate Grand Central Dispatch which is Apples task-based parallelization framework. Some
of the core APIs have started to add messages that take blocks as callbacks.
Exceptions play a different role in Objective-C compared to other common languages like C#
and Java. Errors like a network address not being available or a file not being where its
expected to be do not throw exceptions, you typically get a nil response from the object in
conjunction with it populating an NSError object with information on what happened.
5

9. Cocoa Touch is the MVC-based UI framework on top of which you build iOS applications.
Most iPhone UIs are built around the UITableView control, its list control on steroids with
out-of-the box support for section headers, images, and navigation. Most apps customize
the UITableView heavily to achieve a certain look and feel. It’s a list control though and it
doesn’t really support the concept of columns, everything is a row. You can make a
UITableView look like grid with columns but column operations like sorting are going to be
supported by hand.
When I first started developing for the iPad I was surprised by the lack of controls. Up until
the iPad release.., Cocoa Touch was all about the iPhone. Well the iPhone is used in a
different way than the iPad. You rarely see people using an iPad while walking or driving.
Users hold them differently, they interact with the devices in different ways.
An iPhone user is after some sort of information and is probably doing something else in
parallel, and the Cocoa Touch control set was designed for that user.
I think an iPad user is probably going to be in a more relaxed state. I think they may be in a
more exploratory mood, and more willing to negotiate a complex UI. Well that would
probably call for some additional controls right? Cocoa Touch added the
SplitViewController which is great for displaying parent-child relationships. The Popover
control which is a popup overlay window is also widely used. But that’s it.
I think the lack of controls has spawned a lot of creativity, if you look at Twitter’s app or
6

10. HBO’s app.., those apps are very creative and really exploit the iPad to its fullest. Those are
big budget apps however and writing focused, custom controls for those apps makes sense.
Enterprise & B2B applications normally have more screens and justifying custom control
development is tougher.
6

11. Ok so I am going to demo for you guys a proof of concept application that I worked on last
year. This app was designed to replace a desktop FoxPro application used by clothing sales
reps in the field. This was a large leap forward obviously in technology from FoxPro to iPad.
The choices we made in developing this app were I think very conventional, we drove
down the middle of the road. For data we used SQLite 3 which comes supported out the
box with iOS. The default interface to SQLite is straight C.., which can get tiresome
allocating and de-allocating buffers for all of the bound data. Early on in the project we
discovered fmdb, which is a very thin Objective-C wrapper over SQLite. This library helped
a great deal and gave data access more of an ADO.NET or JDBC feel.
The service layer was very simple. We deployed a RESTful service that generates a SQLite
database file based on the identity of the authenticated user. Rather than waiting for a
unauthorized response from the server and making an additional round-trip we provided
the user’s credentials preemptively by base64 encoding the user name and the password
and adding it to the HTTP header. Obviously you are relying on the SSL transport to secure
the request. The users credentials are stored in the sandboxed iOS keychain. Access to the
keychain is made through a dictionary style interface which I found to be a little difficult to
work with. The keychain is one the big advantages of native apps however in that the user
doesn’t have to supply a password when starting the app. Depending on your security
requirements that may have a big influence on your choice.
For the grid control we choose AQGrid which is an open source project on GitHub. At the
7

12. time there were not that many choices but I noticed there a some more native grids
available now. There is a project called GridMonster on GitHub that attempts to demo all the
salient features of the different grids that are avaialble in one app. It might be wise to get
that project building and running before making any choices or rolling your own.
7

13. Ok this where things start to get pear shaped. Deploying native applications is fairly
complex, and this where Apple really starts to get in our way when trying to build
enterprise applications for the iPad.
At the root of this deployment system are code signing certificates; there are two kinds..,
development & distribution and Apple must issue them to you. They expire every year and
once they expire your apps are pulled off the App Store and will no longer run on a device. I
actually see this is as a good thing in that there are some 500,000 apps on the App Store
and if an App is not being maintained, if its not being purchased.. then its probably OK for
that app to be pulled and unclutter the App Store some. When the current excitement
cools down I would expect the App Store to start contracting.., but I am no holding my
breath.
Provisioning profiles combine certificates with an optional App ID and possibly device IDs.
An App ID is a reverse domain name style identifier that is used by iCloud and the
notification system to distinguish your apps from all the others. Device IDs are unique
identifiers assigned to devices at the factory. As a developer you are allowed to associate
100 devices total to you account. Only development and Ad Hoc profiles require device IDs.
Ad Hoc profiles are intended to be used for testing. You have an app you would like to get
some feedback on or do demos then Ad Hoc profiles are the right choice. There are some
services out there that can help you deliver Ad Hoc builds to users from a single
distribution point, the most popular being TestFlight @ http://testflightapp.com. <<Explain
how TF works>>
8

14. Distribution profiles do not include device IDs, and are for production builds that you intend
to send to the App Store. The profile ties the code signing certificate to an If you are an IDEP
member your distribution profile allows you deploy your app outside of the App Store. You
can build your app, sign it and throw it up on a web server and your users can install it
directly to their device. Sounds perfect right? Well there are some restrictions… you may
only distribute your app to internal employees in your organization. This deployment style is
for in house applications only. Obviously Apple is protecting the App Store by doing this. They
do not want people selling their apps outside of the App Store and avoiding the 30% share
that Apple takes from each purchase.
I have always told customers that something has to change with the IDEP. Its just too
restrictive particularly for B2B scenarios. When I started preparing for this talk I discovered
that Apple created a brand new deployment style called B2B. This deployment style goes
through the App Store. *If* your customer is enrolled in the Volume Purchase Program your
application will become visible to them and they can purchase it. Your app must cost a
minimum of $9.99. I am not sure if this is the answer or not, but its an improvement. I think
a lot of company-issued devices company devices are configured for company email but the
individual logins with their iTunes account to buy music and games and so forth.
8

15. 9

16. So there are probably many more
10

17. ## THROW AWAY
Development allows you debug locally, distribution is basically for everything else. Certs get
assocaited with provisioning profiles in the provisioning portal
##
In the past there where four basic choices for deployments. Development is simply a
developer debugging a build on a device that is connected to their Mac via USB. Even
though that seems like a harmless scenario Apple still requires that the application be
signed by a development certificate before it works on a device. Xcode does a really good
job of syncing the OS X keychain with the provisioning portal and setting up the profiles on
the connected device automatically. You never would notice that code signing is going on if
you were not paying attention to it.
On other mobile platforms like Android for instance you can email your testers an app and
they can install it on their devices with very little trouble.
11

18. So obviously one the first things that comes to mind when we talk about the differences
between a native app and a HTML 5 app is connectivity. Is it possible to have create an
HTML 5 application that the user can launch from the iPad’s springboard and view pages.
HTML 5 documents can utilize an cache manifest file to instruct the mobile safari to hold
files in the application cache.
The document that contains the manifest tag is added to the app cache implicitly, but it can
also explicitly reference dependencies like JavaScript files and have those cached as well.
The app cache file itself has a simple syntax.
The application cache in HTML 5 is always working. If you added a file to the application
cache that file will be served from cache whether or not the browser is offline.
12