Don’t Read The Fine Print


I updated my iPhone astronomy app, “My Messier”. Check it out.
The text size can now be adjusted, and it supports the iPhone X screen size.  I read somewhere that you can determine a person’s age pretty accurately by the distance at which their eyes can focus. The lens of a person’s eye hardens as they age, a condition called presbyopia. This is in addition to all kinds of eye conditions people are born with or acquire, so it helps to allow text size in apps to be enlarged for easier reading.


This is a box of frozen food. After you willfully disregard the nutrition facts, the main thing you want to know would probably be the cooking instructions.


The box is 23×17.5 cm, (9×7 inches) but the letters for this essential text are only 2 millimeters high, with lots of room to make them bigger. Text size and use of available space is important.

Fixed Type

The first version of my app had text with a fixed size. It took a lot of time to adjust the layout so that all the text I needed was arranged the way I wanted, and readable on different size screens. I wanted to support my old iPhone 4s, with its “tiny” 3.5 inch screen. After using the iPhone 6+ with its 5.5 inch screen, I felt like I could strap the cute little 4s to my wrist for a watch. Using the auto layout feature of the Interface Builder tool in the iOS Xcode develpment environment, I could space the text proportionally.  For example, rather than making my code test for how many pixels high the user’s screen is, I can just add a constraint to a line, specifying it to appear at 60% of the screen height, whatever the device. This worked for text spacing, but as for text size, making my app readable on the 4S using small type meant that on the 6+ screen there was a lot of unused space for larger text.
I was trying to get basic functionality on my app first. Because my app worked and I had already spent a lot of time arranging and testing the text, I decided to release it at first with fixed text size, saving adjustable text support for a future update.


Here is a screenshot of the iOS Xcode development environment, with its Interface Builder tool and my app layout. There’s a lot of constraints I put on the text.

Dynamic Type

Apple has an iOS feature they call Dynamic Type, which lets a user set the preferred text size in the main settings of the device, and all apps that support Dynamic Type will adjust accordingly.   Apple keeps updating the operating system, making support for things like adjustable text size easier. In fact, my original release easily supported adjustable text on the Apple Watch. However, when I decided to make an update supporting Dynamic Type on the iPhone and iPad, it wasn’t a matter of throwing one switch — I had a lot of work to do: I had to change every string on every screen to the text styles that support Dynamic Type. If the user enlarges the text size, you can have some text be larger than other text by specifying a “headline” style instead of a “body” style, rather then giving it a larger number of points. If your enlarged text doesn’t fit the screen width, you can break the text onto another line, or truncate it with an elipsis (…). The user might go out of the app into the system settings, change the size, and then come back to the app, so my code has to check for that event and refresh the screen. My screen has a Table View (scrolling list), with each cell having multiple items of text and images to arrange, and if the text size changes, the cells in the table view get taller .


There is an option in the system accessibility settings that enables even larger text, up to truly gargantuan sizes to accommodate even severe vision disabilities. Not all of the text in my app or the system can be enlarged, and some can only be enlarged up to a maximum size.

When a user selects an item in my app’s object list, it goes to a page with detailed information. My app was intended to give basic, quick reference on objects, so the detail page did not scroll– all the information available was there at a glance (including a link to Wikipedia for much more.) But if the largest text sizes are selected, there is no way the data would all fit, even on the largest iPad. I decided to just limit the text size.  Maybe I’ll change to a scroll view for larger text in a future update. The view had three elements in one row at the bottom, so I had to test it with the maximum size strings it might have, to find sizes that wouldn’t be too squished, on different size screens. I ended up checking the size of the user’s screen, and using that to determine the maximum text size.


Here are detail pages on the iPhone 6+ with increasing text size.

I had to test that all the text was readable, on all the possible text sizes, on physical devices I had, and on simulators for ones I didn’t.

Here are screen shots of devices, at the default text size, from left to right: the Apple Watch, the iPhone 4s, 5s, 7, 6s+, and the iPhone X. (They are to scale by pixels, not by physical size– different displays have different pixels per inch)

So it was a struggle, juggle, and compromise between aesthetics, functionality, compatibility, and development time, but hopefully the app is more accommodating to people’s vision and preferences than before.

iPhone X

Supporting the iPhone X with its new taller, narrower screen shape was easy though. Older apps are unaware of this shape, so for compatibility, the iPhone X will display them with blank spaces at the top and bottom. If the app uses Auto Layout in development, like mine, it simply has to be rebuilt, without code changes, using latest version of the operating system, and it will use the full height of the screen. When submitting to the App Store, you can provide screen shots of the app from the iPhone X, so the app looks more attractive, rounded corners and all, to people who own one (unlike myself, who had to use a simulator for the X screen shots.)

My Messier iPhone X Store Screen Shot


How were the sales for the first release of my app? I won’t say how many units, but one thing I was pleasantly surprised with as a first time, one person, American, application developer, was how many countries my app was installed in. I only released it in English, but it had more sales overseas than in the United States. Before I released an app, I didn’t think that I would have any measurable international influence, that something I made personally would be used halfway around the world by a person in say, Lithuania.
According to my reports from Apple, my app has been installed in:
The United States, Canada, United Kingdom, Switzerland, Spain, France, Germany, Netherlands, Italy, Austria, Czech Republic, Hungary, Greece, Lithuania, Norway, Poland, Sweden, Turkey, Australia, Japan, Republic of Korea, New Zealand, Pakistan, Brazil, Chile, Mexico, Peru, India, and South Africa.
Notably, no sales in Russia or China. I wonder if this has to do with the rating of the app, 17 and older, required because it supports “unrestricted web access”, namely, links to Wikipedia.
Next time I’ll give more consideration to supporting other languages. When I was making the app, I had to decide on “feature freeze” at some point and release it. In hindsight, it would have been easier to support multiple languages as well as Dynamic Type from the beginning of my project, but so are a lot of features that would be nice to have.

So make your own app and change the world.
It’s a small world but it doesn’t have to be hard to read.

This entry was posted in apps, astronomy. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s