Menu

Colin Devroe

Reverse Engineer. Blogger.

Follow: @c2dev2, RSS, JSON, Micro.blog.

'

App icon design, one size does not fit all

Yesterday I reposted Becky Hansmeyer’s vent about having to create multiple icon sizes for her app. I feel her pain. I recently completed an app for both iOS and Android and so I had to create just over 1,000,000 icon sizes. At least it felt like it.

So, like her, I too would like Xcode to create all of the sizes I need from a single larger file.

The issue with this though, which I’m certain Becky knows but she still just wants things to be easier anyway (so do I), is that one size does not fit all in icon design. Each size needs to be considered individually – especially with complex icons.

To quote the venerable Dave Shea from 2007:

One of the more deceptively time-consuming things you’ll do when creating an icon is producing out size variations. If you require a single icon in more than one size, the time you spend designing the first size is only about two thirds of the work you’ll end up doing; the other third lies in tweaking it for different dimensions.

As the size of the icon gets smaller details get lost and so the designer needs to begin removing elements, increasing stroke widths, and the padding around the elements within the icon.

It is why I designed the Summit icon (which I plan to write about in the coming weeks) to be so utterly simple that it will scale without very many tweaks as the icon reduces in size.

As you can see the icon changes very little from large to small. I remove the gradient, tighten one or two things, but that is it. So I’m able to use a Photoshop template that automatically creates every single size from a single Object – and then remove the gradient from the smaller sizes, and then finally increase the spacing at the smallest sizes.

So far this has worked well in my testing on my devices. I still have more I’d like to do with the icon but it will have to do until I get a new beta out. I haven’t shipped a beta in months because I’m rebuilding Summit for both Android and iOS, as well as have a few other irons in the fire.

 

 

Repost: Becky Hansmeyer re: app icons

👉 Becky Hansmeyer:

Xcode should, by default, generate app icons for all sizes from a single artwork file. That would eliminate such an obvious pain point for app developers and designers.

Observations on building my first iOS app in Swift

In early June I decided I wanted to learn iOS app development using Swift.

I’ve made a lot of progress over the last month, building two apps that I can use on my own phone, and one app that I’m now in beta testing via TestFlight with a few friends. Over the last month I’ve made some observations on the process of building an iOS app, the Swift programming language, Xcode, iOS frameworks, and the various other bits needed to make an app. I thought I’d take the time to jot those down.

These are in no particular order:

  • Swift is growing on me rather quickly. The idea behind Swift has always interested me, but I hadn’t really given it a try until now. Like any new language you need to work with it for a time before some of the things that you may not like about it, you end up seeing the wisdom in.
  • I’m very glad I waited until Swift 3 before trying it in earnest. The tutorials I’ve come across for earlier versions make it clear the language has matured in a short period of time.
  • Using Storyboards in Xcode is not intuitive whatsoever. I know many people avoid them altogether (from what I’ve seen on YouTube). Unless you watch someone build a Storyboard you’d likely never, ever just figure it out.
  • iOS frameworks are bulky. It is no wonder so many apps are so big. Just including one or two frameworks for my very simple first app ballooned the app to over 15Mb.
  • That being said, iOS frameworks are very useful. With just a few lines of code you can get something working quickly.
  • Playgrounds are very useful to learn Swift.
  • The Playgrounds compiler can become stuck rather easily. Especially if you paste in a bunch of code from your project to mess around with and get it to work. I’ve had to restart Xcode several times.
  • Xcode has crashed on me a few times over the last month. Crashes on macOS (and also most Apple apps) are very rare. So to be working on something so fragile seems out-of-character. Especially with how simple my apps are currently.
  • Auto Layout baffles me still. I have a working UI for one of my apps that works across multiple device screen sizes. But it is far from what I’d want to ship with. I’ve watched a lot of videos on how to use Auto Layout but I still can’t make heads or tails of it. I’m waiting for the moment it clicks.
  • The connection between labels and buttons and other UI elements in your Storyboard and your Controller class is far too fragile. You should be able to rename things, delete things, move them around without completely blowing everything up and starting over. Example: If I CNTRL+Drag a label onto my Controller and create an Reference Outlet for it… I should be able to rename that Outlet without needing to CNTRL+Drag again. I don’t know how, but somehow.
  • Did I mention that Auto Layout baffles me still?
  • Building and deploying an app to iTunes Connect in order to add to the App Store or Test Flight is an entirely un-Apple-like experience. There is no Step 1, Step 2, Step 3 type of workflow. Similar to Storyboards it is not something you can figure out – you must watch or read to learn. It feels like it was never designed by a Product person.
  • Building an app that resides on a device like the iPhone is an amazing experience. While I’ve always been able to load my web apps on a phone, and I’ve built some apps that use a WebView to deploy across multiple platforms, this is the first time I feel like I’m touching my app when I use it. There is nothing that comes close to native UI.
  • Also, building an app that requires no connection to the web has been really fun. It is so fast! I’d like to move forward by trying my best to keep HTTP request at zero or as low as possible.
  • The amount of information an iOS device knows at any given time is pretty amazing. It can know (with the user’s permission) where it is, what altitude it is at, which way it is pointing, how many times the person’s heartbeat that day, what it is looking at, etc. etc. Amazing to play with these features.
  • The Xcode IDE is really incredible to use. You may not remember a framework’s properties but you can just begin typing a reasonable word and expect that Xcode will figure out what you’re trying to accomplish. Also, if you happen to write older syntax because you’re following an out-of-date tutorial, it will automatically convert it to the most recent syntax.

Overall I’ve had a positive experience learning to build an iOS app on my own. Going from having an app in TestFlight to shipping an app feels like preparing to cross a desert on foot. But, I’m enjoying my experience so I’m going to trudge forward to do so.

I hope to ask for public beta testers of the app in a few weeks or a month.