I have a minor love/annoyed by relationship with dynamic type. Dynamic type is a system that lets users control the base size of the type used, and then the app configures its type sizes relative to that. Given that I have now reached the age where using a computer/tablet/phone almost always means needing my reading glasses, from a personal standpoint, I love it. Of course, back when I set my personal computer to use the smallest available type so that I could maximize screen space for coding (dual monitors weren’t an options for me then), it also would have come in handy. So what’s not to like?

When iOS first introduced dynamic type, most of my clients were web and print oriented and were working with designers who wanted complete and utter control of the fonts used, which meant custom fonts. Which weren’t well supported by dynamic type, quite aside from the issues of needing to imbed custom fonts in an application. (Webfonts are a wonderful thing, but they spoiled the developers I was working with and made transitioning their ideas to native apps more time consuming and painful on all sides.) Still, it was a great idea and I used it when I could get away with it.

But there was another issue. Even the Apple apps didn’t always play well when the larger accessibility sizes were used. And by not playing well, I mean the apps delivered by Apple would almost always truncate text at the largest sizes which could render an app all but unusable. (Mind you, this was also back in the era of the iPhone 5, so screens were smaller with less resolution.)

Just as you can roughly categorize people as dog people or cat people, there is also a division between Android people and Apple people. Just as with pets, it’s not a sharp line, but the trends are there. Me, I’m in the apple camp. Apple products generally tend to behave, and expect me to behave, in ways that I can understand. It makes the tech experience less stressful and more enjoyable. So when an Apple UX experience fails, it can be especially grating. Today’s peeve is with the iPhone implementation of Messages.

Just as there are dog people and cat people, and Apple people and Android people, there are also those who carefully clear those little unread badges and those who revel in seeing how large an unread count they can accumulate. I’m not entirely consistent about it, but I tend to be in the clear the badges camp, especially when it comes to messing apps.

Let us consider a normal interaction. I notice that I have received a new message. It’s probably spam, but you never know. I open the Messages app and I can tell by the sender and the first line of the message that it’s not urgent and I’m not interested in responding or even taking the time to open it up. I don’t want to mute or block the sender because every now and then they send something I really am interested in, but I just want to mark this message as read so that it clears that stupid flag and I can stop thinking about it. My immediate reaction is to assume that the Messages app will work like the Apple Mail app; swipe right and you can quickly mark the item as read. It’s quick and easy and I use it all the time. But when I do that in the Messages app, instead of marking the item as read, it pins it to the top. Seriously? This is nearly the opposite of what I was expecting! And the action is so ingrained that I find myself accidentally pinning messages all the time, with a guarantee that they are the messages I am most unlikely to want pinned.

Yes, it’s a minor frustration. Yes, I did figure out how to mark as message as read without opening it. It still bothers me.

[It’s been awhile since I’ve written here. No apologies, but we’ll see if I’m back.]

I’ve been in a bit of a rut of late. I used to love creating apps and would tinker with things on the side. But it’s been difficult to muster any enthusiasm for that in far too long. I still haven’t entirely figured out why. Is it burnout? It’s not because I’m writing too much code these days; most of my time is spent in project wrangling and communication. Part of it is that the native app side of our business has fallen off. It means I get to learn a broader range of tools by needing to handle Android and also writing in Xamarin. But it also means I don’t get to do a lot of work in any one tool set. And if you’re going for efficiency, using a tool set only once every year or so is definitely not the way to go.

Recently I found myself wanting to create another useful to me toy app and I decided to use that as an excuse to dip my toes into SwiftUI finally. And it hasn’t been bad. I like that it isn’t an entirely new ecosystem and is instead an adjunct to Swift. It also feels like an excellent way to develop interfaces that work well across a wide variety of screen sizes and aspect ratios. And yes, it’s nice to be able to enjoy learning something new in my trade. It also makes me think that if I had my choice, I’d prefer to be working entirely in Apple ecosphere, iOS, iPadOS, macOS, and even watchOS. (I still haven’t worked with watchOS yet) I need to think about that.

Speaking of Apple and covid, they announced that their stores were open again, and they are. I’ve been dealing with an irritation with my iPhone and have been waffling between putting up with it until new devices are announced this year, seeing if I can get my current phone fixed, or just going ahead and buying a new one. I walked into my local Apple store yesterday and found out that the soonest Genius Bar appointment I could get was Saturday. Ugh. So could I just buy a phone today? Well, yes and no. If I went online to make my purchase I could pick it up there, but if I needed to actually talk to someone, then I’d need to make an appointment, and the soonest available appointment was this weekend. It didn’t appear to be an issue with the number of employees as there seemed to be as many of them on the floor as I was used to seeing pre-covid, but I could be mistaken.

I did not pass Go. I did not spend over a thousand dollars. I left. And then I went online to make a Genius Bar appointment for this weekend so I can find out if it’s an easy fix. Then I should have enough information to decide whether to go ahead and get an iPhone 12 or wait for the new models. I’ve already had this one for a year longer than I had planned, so I will be buying a phone one way or another, it’s just a matter of which one. And now I’m thinking about whether this is all a good sign for Apple, because there are a lot of people willing to schedule appointments to spend money with them, or a bad sign because they might not have the staff to service the demand. And then I think about how I’m planning on replacing my laptop next year and how much money I spend on Apple products in any given year.

Once upon a time I used to work on side projects, writing mobile applications for other people. In an ideal world I would still be doing it, although maybe not for money, because that can play havoc with work/life balance issues. I love coding, but one full time job as a coder at a time is really enough for me. On the other hand, as I move into more and more management, it becomes more important to keep my hand in the coding game. But then you run into the problem of what to code.

Seriously, it isn’t easy to come up with a truly useful idea for an app, and that really isn’t my goal. What I want is a project that stretches my skills in some area, that is self contained enough that I can finish it well on my own, and that can plausibly bring at least some joy to someone. Which means that my favorite types of app to work on are casual games and fun learning toys.

Long ago and far away, I developed a toy app that let you count change, and that included a fun animation of tossing coins into a glass jar, complete with public domain sound effects and graphical assets I created from my own photography. Tweaking the animation curve and figuring out how to composite the graphical assets was fun. (Spinning coins!) I also learned about sources of public domain sound effects as well as the fact that many currencies are carefully protected by copyright. And that’s why my grand scheme of releasing localized versions for different currencies came to a screeching halt.

About a year ago I made quite a bit of progress on another app, this one related to fencing. Again, I learned a lot from it, including trying out more than one cloud service. In the end though, the design just never gelled and the use case never quite worked, so I abandoned the development on it. I may revive it some other time if I can find a way to solve the issues it had, but it was still an excellent project.

This afternoon I got waylaid by a casual game idea. I have some user interface design issues to solve and lots of user experience work to do on it, but a couple of hours of poking at the basic back end design makes me think I have an idea I can execute. Now I just need to spend some time dreaming up what the actual experience will be. It won’t win any awards but that’s not my goal. I just want to make something silly that will make people smile while giving me an excuse to play with code while I learn.

Never assume that your testers (yes, even your internal test team) know how to get an app onto a device. There are otherwise wonderful and intelligent people who believe that new app builds magically appear on devices without them doing anything. Chances are good that, like me, you are one of those clueless people in other contexts, so be patient, and over-communicate the procedures for installing. And don’t assume they will remove previous versions.

If your mobile application has an internal database, pay attention to when the database schema changes. If the schema changes, you will need to add code to upgrade the copy of the database that resides in the app’s sandbox. You also need to thoroughly test that update code with any and all publicly available prior versions of the app. Yes, it’s a pain in the tail.

Never assume that your users know what version of the app they are using, what version  of operating system they are using, or even what type of operating system they are using. They are more likely to know they are using a Samsung than they are to know that the OS is Android. (On the other hand, knowing the manufacturer can be very useful when you’re dealing with Android issues!) You’ll also be lucky if they know which device model they’re using. Consider whether you can get some or all of this information from analytics reports before you release the app.

Never assume that the device has connectivity, not from a user support perspective, but particularly not from a code implementation perspective. Plan to handle the effects of intermittent connectivity on database functionality, external server syncing, and from a user interface perspective. Don’t just rely on the status bar to tel the user what’s going on and why something isn’t working.

I’m Sam Herdman. I am currently working as a Mobile Development team lead in the Kansas City area. I’ve been working as a programmer since 1987 and working in mobile development since 2012.

I’ll be chatting here about mobile development, being a mobile developer, and other topics that might impact that.

Regular updates will be on Friday mornings.