Gregory Hill, Author at Applied Information Sciences

Previously, we looked at how to implement localization of an iOS app using storyboards. Then we discussed how to localize text that is generated programmatically. In this final article, we will examine how to determine the current locale of the device, and how to use that information to communicate with a web service. This is obviously very useful in those situations where your app is downloading data from a web service and needs to be able to display the correct text for the current locale. Read More…

Gregory Hill

This post is the third part of an ongoing series on localization of iOS apps. Please read part one and part two.

In part two of this series, we looked at how to implement localization of an iOS app using storyboards. Today we’ll continue with that app, and examine how to localize text that is generated programmatically. We’ll also clean up the project a bit, to bring some organization to the localized data files.

This project is available at the AIS GitHub. Read More…

Gregory Hill

This post is the second part of an ongoing series on localization of iOS apps. Please read part one here, if you missed it.

While this post on the MacRumors Forum is a good tutorial for bringing Localization (L10n) to your iOS app, it’s a little sparse in detail, has some updates that change the process, and assumes a few steps. A couple of bugs have also been discovered that need to be worked around to successfully initiate localization in a new iOS app in Xcode.

Today I’ll attempt to clarify some of these steps, and dig into the minutiae that are important to a successful development and deployment cycle. What follows is an example of creating an app from scratch and adding localization features. Read More…

Gregory Hill

With the increased globalization of the economy, there is an obvious need to create mobile apps that handle multiple languages in a clean and extensible manner. This is known as localization (L10n) in the software development community, and various platforms deal with it in their own unique ways. We will look at how iOS manages L10n here, and the decisions that have to be made in order to stay on top of a dynamic situation.

There are several resources on iOS L10n available, both in official publications by Apple, and some articles and blog posts written by members of the development community:

Apple provides a home page for Internationalization (I18n), with links to several additional detailed sources, including WWDC videos.
There is an excellent tutorial on the MacRumors iPhone/iPad Programming Forum that goes into great detail on both how to convert your app to handle L10n and managing the app on an ongoing basis.
For apps being developed to target iOS 5, using pre-Xcode 4.5, Ray Wenderlich’s blog provides a good starting point with this blog post.

This article will take a high-level look at what needs to be done to fully localize an app. Three follow-up articles will look at the nuts-and-bolts details of how to accomplish this through building an Xcode iOS app from scratch. We’ll look at creating an app with storyboards, and the process of configuring the project to localize these storyboards. Next, we’ll cover how to handle localization programmatically, if you find you have to manipulate text before displaying it. Finally, we’ll wrap the series up with a look at how to communicate with a web service and identify the language of the data you are expecting to download.

Gregory Hill

For the last couple months, I’ve been working on a new mobile application for an AIS client. It is an iPad app, targeted for iOS 6. Although I am quite well-versed in many of the iOS standard libraries, there is always “further east” to go, and I’ve really stretched my wings with this project and explored some interesting UI features. One thing in particular that I dug really deeply into is Interface Builder and its new integration into Xcode 4.x. I’ll discuss more of that in a later post, as I explored some interesting features (and limitations).

What I’d like to discuss now is the use of static libraries in Xcode for a couple different reasons. First, I have several classes that I think will be helpful to the developer community (both here at AIS and beyond), and I will be building static libraries to share with any of my colleagues who want to use them in their iOS projects. Second, being able to import static libraries into an existing Xcode project can be a little involved, and I want to outline the process in a way that proves to be repeatable. And of course, the best way of learning is to teach, so I’m looking to solidify my understanding of the process by putting it out there for any of you to try it and punch holes in my logic. Read More…

Gregory Hill

One of the tasks we are beginning to explore at AIS is developing and distributing mobile applications for our corporate clients. One common scenario will be for these apps to be available only for their employees, or a select group of their clients. So distribution through Apple’s App Store, for example, may not be an acceptable solution.

There are several options for distributing enterprise iOS applications, if we can’t (or don’t want to) go through the App Store:

1. Ad Hoc distribution. This involves building the distribution files, distributing them to the clients (via email or posting them to a server), and having them drag the files to iTunes and then synchronizing their devices. That’s a little messy. And it requires repeating the process every time there is an update to the app.

Again, this is a messy process, and will have to be repeated for each update and new app.

2. iPhone Configuration Utility. Apple’s iPhone Configuration Utility (Mac version; Windows version; documentation) is another option. This leaves the task to the system administrator, and is labor intensive. The SysAdmin will either need to attach to each device, and install the provisioning profiles and the apps, or email the configuration profile to each user. A generic profile can be used across the organization, but if username and password management are a part of the profiles, then it gets very complicated, very quickly. Again, this is a messy process, and will have to be repeated for each update and new app.

3. Mobile Device Management. The SysAdmin can install apps through MDM (Mobile Device Management, requires sign-in). Again, device management is required, but MDM allows for remote management once the device has been initially configured. When a new or updated app is available, the administrator creates a new payload, sends a push notification (through Apple’s Push Notification Service) to the appropriate client devices, and the devices execute the command (in this case pulling down and installing the app in the payload). If MDM is already a feature in the organization’s administration processes, this is a viable option.

4. Distribute apps wirelessly, using the Over the Air (OTA) process. This is the route I’ll discuss in detail, as it seems to be the most straightforward and easiest to implement of the available options, especially if MDM is not applicable. There are some wrinkles, too, which can automate the process of updating/upgrading the apps transparent to the users.

BlogPosts by Gregory Hill