The Breakroom

Linea + iPadOS = BFFs

September 16, 2019

By Webmaster

Linea 2.7 with Rob McCallum illustration of future lady

Today’s update of Linea for both iPad and iPhone includes support for iOS 13, frequently requested features from our community of users, and makes sketching easier and more fun than ever. If you enjoy visualizing your ideas, getting work done, or just doodling, today’s update is right up your alley.

The Darkness and the Light

We’ve been working hard to make Linea fully compatible with Apple’s new operating system. One of the most compelling new features, Dark Mode, is now fully supported in both Linea Sketch and Go. In addition to tool, layer, and color palettes, the dark working environment has been extended to other parts of the app.

Linea's project view running in Dark Mode under iOS 13

This means that the project view, popovers, preferences, and related interface elements all look great when running with iOS 13’s new appearance. If you’re sketching in low light conditions, Linea running in Dark Mode is a welcome sight for sore eyes. We think you’ll be pleased.

One Is Good, Many Are Best

One highly requested feature from our customers has finally arrived – support for multi-page PDFs! With just a few taps, you can now export an entire Project folder of sketches into a single PDF document. Open the main Project view and tap the Project’s actions icon (⋯) and select “Export As PDF…” Linea collects all of the sketches and gives you options to customize the final appearance of the file, including margins, background color, and more.

Linea's project view running in Dark Mode under iOS 13

If you don’t want to save out an entire project, you can open the folder, use Select to choose individual sketches, and use the actions menu to generate your PDF. These all-in-one documents are great for presentations, putting together a storyboard, printing hard copies, or sharing your work with others.

Bigger, Better, Quicker

We’ve added a new feature that let ZipLines snap to 0°, 45° and 90°. This makes it a lot easier to draw perfectly straight lines at fixed angles, without the need for a grid or an enclosed shape. It’s super handy, but can be disabled in Settings if you choose.

selecting the new larger pen sizes in Linea

If you enjoy drawing with Linea’s pen tool, you’ll be pleased to know we’ve also added six larger sizes for sketching. To access these new sizes, open the pen’s options and flick the size indicators to page between sets. These new pens make inking and outlining large illustrations easier; they also work great for calligraphy.

Finally, comes the ability to set app-wide defaults for your canvas preference. The paper type, background, and template preferences from any existing sketch can now be used as the default for new drawings. Simply open an existing sketch and tap the sketch actions icon (⋯), then choose “Set Canvas as Default”. Linea remembers the setup and will use it from then on: quite a time saver!

One More Thing

We’ve also optimized Linea Sketch to work flawlessly with Apple’s newly announced 10.2″ iPad, so if you’re looking for a great sketching device at a great price, we’ve got you covered.

Don’t forget to check out our Tips & Tricks page for some great ways to improve your workflow. There’s also Sketch’s and Go’s version history pages for the complete list of changes.

If you’re not using Linea yet, today’s update is a great reason to get on board! Head on over to the App Store to download Linea Sketch for iPad or Linea Go for iPhone and you’ll be creating in no time!

It’s Hip to Be Square!

September 6, 2019

By Ged Maheux

Back in the day all of us here at the Iconfactory lived, ate, and slept customization. If there was a way to change the appearance of something on our desktops, from icons to wallpapers and even the Mac’s overall look and feel, we forged ahead and changed it. Indeed, we built our early business around the fact Mac users loved to change their icons, wallpapers, iPulse jackets, and lots more.

Times have changed of course, and Apple locked down many of the fun pieces of software we used to enjoy so much like Kaleidoscope, iControl, and CandyBar. But today we’re reclaiming just a tiny bit of that nerdy battlefield thanks to our most recent cross-platform updates to Twitterrific. We’ve had theme support in Twitterrific for years, but now we’re giving you the tools to create your own themes for both macOS and iOS, as well as the ability to share them with other Twitterrific users.

Ollie pulls out his glasses and pocket protector in the Nerdy Bird app icon

We’ve set up a Dropbox archive that contains all of the default themes used in Twitterrific. These themes make great starting points for anyone who wants to customize the appearance of Twitterrific’s timelines and windows.

To help make this process a bit easier, we’re also releasing the internal tool we use to create these themes. Nerdy Bird may not be a slick, polished app, but it gives you everything you need to open an existing light or dark theme, tweak it, and save it just the way you like. Themes can be shared on your devices by simply dropping them into the iCloud Drive > Twitterrific > Themes folder: they immediately become available on both platforms. Neat!

We’ve also included a repository where you’ll find a collection of custom Twitterrific themes contributed by a few brave souls who have already taken the plunge. We hope to grow the number of themes available in the weeks ahead, but there are already a handful to download now. If you’ve created a cool theme and want to share it with the Twitterrific community, write or tweet and let us know – we’ll add a special spot just for your creation.

There’s even a helpful online tutorial about Twitterrific theming from Ringgit Malaysia. He outlines the various colors that go into the creation of one of Ollie’s complex themes, so check it out!

We’re not gonna lie, creating a custom theme is a complex and challenging task. But if you’ve been bitten by the customization bug, like we were long ago, have no fear: you’ve got a fever, and the nerdy prescription is finally here. Have fun, play safe, and enjoy yourselves!

Twitterrific 5.4 and 6.0.5

August 28, 2019

By Webmaster

Twitterrific 5.4 for macOS showing off new and improved media handling

Twitterrific 5.4 for macOS has been released with support for viewing full images right in your timeline, Twitter’s new quoted tweets with images, a bunch of great new themes and app icons and more! On the iOS side, Twitterrific moves to version 6.0.5 and gets a cool new theme, Trogon, plus speed improvements and important fixes for some nasty bugs.

With these releases we have unified our themes across platforms which means you now have all of the same options on the desktop as you’ve been enjoying on iOS. If you’re feeling especially adventurous, you can even make your own theme files, drop them in Twitterrific’s iCloud Drive folder, and use them on every device.

We know that sometimes you still have to use in Safari, so we’ve bundled Fixerrific with Twitterrific 5.4. Fixerrific is a Safari Web Extension that cleans up and gets rid of the clutter. Once you install Twitterrific for macOS, head to Safari’s preferences and activate Fixerrific under the Extensions tab. This will hide Twitter Trends and the Who to Follow sidebar elements in the new Twitter design which lets you focus on your tweets.

Be sure to visit the Twitterrific website for the entire list of what’s new, then head to the App Store and download Twitterrific 5.4 and Twitterrific 6.0.5 today. Enjoy and thanks for your support!

The Curious Case of the Core Data Crash

August 26, 2019

By Sean Heber

Detective Heber hot on the trail of the Curious Case of the Core Data Crash

For several years, Twitterrific has been plagued by Core Data crash reports that I haven’t been able to figure out. It was so bad that nearly all of Twitterrific’s reports were from this framework. I knew I was doing something wrong, but didn’t know how to fix a problem I couldn’t reproduce. After lots of investigation on Twitter and Google, nothing ever turned up.

Worse, it got to the point where I mostly ignored this seemingly unsolvable problem.

Recently, there was a breakthrough. Three people used the new TestFlight feedback mechanism to report a crash on iOS. They also noted the app was in the background at the time. I had long suspected that was the case with this bug, but always assumed I was missing something important.

Rather than look at the crash reports inside Xcode’s Organizer as I usually do, I downloaded the report attached directly to the feedback report and took a look at the file. The stack trace matched the Core Data crashes I had seen many times in Organizer. No surprises there.

I was about to close the log in defeat when I noticed that the Termination Reason was something unfamiliar. Xcode‘s Organizer does not report the cause of termination — after all, one would assume the reason was BECAUSE IT CRASHED, DUH!

But here’s the thing: that assumption is totally wrong. iOS routinely terminates apps for all sorts of reasons, including using too much memory or taking too long to do background processing. I don’t know why this information isn’t included in Xcode’s Organizer, but it’s a critical piece of a debugging puzzle.

Naturally, the termination reason in the raw crash log isn’t some nice human-readable message. It’s a hex code and a cryptic string that maybe suggests which subsystem is responsible for it. Why make crash reports easy for the developers, right?

In this Core Data crash report the termination reason was: Namespace RUNNINGBOARD, Code 0xdead10cc. This nugget was something new I could search on the web for. Many of the results were just pasted crash reports with little attention paid to the significance of the termination reason.

But one result led to Tech Note 2151, with the code listed at the end under Other Exception Types:

The exception code 0xdead10cc indicates that an application has been terminated by the OS because it held on to a file lock or sqlite database lock during suspension.

Holy crap! I’ve been searching for this for ages and here, finally, was a clue! I started looking around the code in search of a trigger for this exception. I discovered that Twitterrific was sometimes closed while it was doing a network download and iOS left it running in the background long enough for the network request to finish. But not long enough for the database update to finish.

Due to incorrectly placed task markers, the background task would be marked done before it had finished saving the database. When things happened in the wrong sequence, iOS would unceremoniously kill the process — making it look like it had crashed somewhere inside of Core Data.

I spent several days reworking a bunch of old code to ensure that task markers were started and ended in the proper sequence, and to ensure that the task wasn’t marked as complete until after the entire process was done.

Lo and behold, this appears to have worked!

Prior to the fix, one recent build had over 90 crash reports from TestFlight in the span of just four days. Three days after releasing a new build to TestFlight, there were only 9 crash reports, and they were all caused by a simple bug introduced during refactoring.

So there you have it — another exciting tale of me doing things wrong for years. Remember kids, I’m a professional!

xScope, Catalina, and Screen Recording

August 16, 2019

By Craig Hockenberry

We just released a new version of xScope that adds compatibility for the upcoming version of macOS Catalina. You can update using the Mac App Store or with “Check for Updates…” in the xScope menubar. If you’re new to xScope, you can download a FREE trial from the product website.

The most visible change on Catalina is a series of new prompts for Screen Recording after you first launch xScope on the new OS. This slight inconvenience is a good thing, because there are a lot of bad things that could happen if an app abused this feature.

We have never stored the screen recording except by explicit user action, such as taking a screenshot. We have never performed any processing on the image that would extract your personal information. And we never will, so we hope you’ll grant us permission to use this feature.

The first dialog is a prompt by the app that explains why we need the permission:

xScope screen recording dialog in macOS Catalina

After you dismiss that dialog, you’ll see the new prompt from macOS. Click Open System Preferences to continue and give xScope the required permissions.

macOS Security & Privacy preference panel showing xScope with a blue check next to it

If all goes well, you’ll end up with blue checkmark next to xScope on this screen in System Preferences:

macOS asking to open System Prefs and grant xScope permission in Catalina

If you choose to deny permission, xScope tools like Rulers, Guides, Frames, Crosshair, and Text will continue to work, but in a limited fashion. It’s your choice and we’ll do our best to respect it.

For more information about this release, check out the version history. If you love the Doctor Who wallpaper in the screenshots above, it and many others are available from our Patreon account. Enjoy!

Linea on iPadOS: Hold Off for Now

June 24, 2019

By Craig Hockenberry

We’re all excited about the changes coming in the new iPadOS. The urge to install the new shiny is strong with this one!

But before you start your download, be aware that you’re likely to have problems with both Linea Sketch and Linea Go. Some early adopters have lost access to drawings and aren’t able to create new sketches.

We’re still trying to understand what’s causing this data syncing issue. It may be specific to Linea or a more general problem with iCloud. As we learn more, we’ll update this post.

If Linea is a part of your workflow, our current recommendation is do not install the iPadOS or iOS 13 beta.

Updated July 1st, 2019: We have released version 2.6.1 which blocks Linea from running on iOS 13. If you absolutely need to run on the new OS and are willing to take the risk of data loss, we can add you to our beta test. Please get in contact to set this up.

Updated July 2nd, 2019: The release notes for iOS 13 Beta 3 indicate that there are many known issues with iCloud. If you are using a beta of either iOS or macOS that’s connected to iCloud, you run the risk that the beta will delete information and the data removal will propagate to devices using production releases. If you have any device running a beta release, make sure you have a backup of your iCloud Drive. The easiest place to make this backup is on a Mac running Mojave.

Updated July 9th, 2019: These problems with iCloud are affecting many apps. If you have an iOS or macOS beta installed, we recommend that you disable iCloud on the device or login with a test account where you don’t mind losing data. Otherwise, you’ll lose data on your production devices.

Updated July 10th, 2019: We submitted a detailed incident report with Apple’s Developer Technical Support only to find out that beta releases are not supported. If you’re a customer using iOS 13 or macOS Catalina, this means app developers can’t get any direct help for these iCloud issues. All we can do is submit feedback and wait for the data loss to stop (FB6337265).

Updated September 5th, 2019: Our experiences with iCloud have improved significantly in the most recent betas. We’ve also heard reports that all of the server changes that were causing the issues have been reverted, so you’re back to using the same iCloud you had in iOS 12. We also have an updated version of Linea waiting for the final release of iOS 13.

For an honest look at our experience over the past few months, and recommendations for Apple to help prevent this kind of data loss, please see my blog for an in-depth report.

Introducing Twitterrific 6 for iOS

June 13, 2019

By Ged Maheux

Twitterrific 6 logo over a field of iPhones and iPads running the new app

Today we are proud to release Twitterrific 6.0 for iOS! This is one of the biggest updates of Twitterrific ever, representing over 50 bug fixes and improvements as well as a ton of new features. We’re very excited to get all of this amazing stuff we’ve been working on for so long onto your device and into your hands!

Media Unleashed

Now with Twitterrific 6, tweets or direct messages with a single photo, video, or animated GIF will display the attachment at its native aspect ratio. This means you can see the whole thing right in your timeline, without having to tap through to the media viewer. Tweets with more than one photo still show the attachments in a grid to help preserve screen space, but the layout has been adjusted to do a better job of making more of the photos visible (while still focusing on human faces, if possible).

Autoplaying video and animated GIFs

Seeing full-sized images on our tweets felt great and it was obvious that we needed to take things a step farther – so we added support for auto-playing videos and animated GIFs right in the timeline. When a tweet with an animated GIF or a video gets scrolled into view, Twitterrific 6 immediately starts playing it without you needing to tap anything. If the video has sound, an icon appears so there are no surprises when you tap through – we never autoplay audio!

Recently Twitter added the ability to attach photos, videos, and GIFs to quoted tweets, so we brought that functionality to Twitterrific 6 as well. These new, richer tweets will appear correctly in the timeline and you can post them yourself – simply quote a tweet and add your favorite reaction GIF!

To Boldy Go Where no GIF Has Gone Before

Speaking of reaction GIFs, in Twitterrific 6 we’ve made it easier than ever to find and attach them with our new built-in support for GIPHY. While composing a tweet, tap the GIF button to search for just the right snarky animation that captures how you really feel. We’ve even built in handy shortcuts for popular GIFs, memes and our favorite Swear Trek reactions – it’s only logical.

Searching for that perfect GIF in Twitterrific 6 is a snap

Twitterrific’s new GIPHY search in action.

After you’ve attached your GIF, photos, or video to a tweet or direct message, it’s helpful to add a textual description for people who use assistive technologies like screen readers. Twitterrific has supported this for a long time, but in Twitterrific 6 we’ve improved the experience. Tap the attachment’s thumbnail to see a large preview and type a description for it. If you’ve added multiple photos, you can hit the return key on the keyboard or swipe between them to annotate each image quickly and easily.

A Theme By Any Other Name

Twitterrific 6 is all about using Twitter the way you want to use it, so if you’re not a fan of autoplaying videos, you can turn them off. If you don’t want animated GIFs to autoplay, you can turn those off too. If you just want to see the username of everyone in your timeline and skip seeing their full name, you can even do that! We also added a feature that increases the contrast of text in the timeline by forcing it to use either full white or full black no matter which theme is in use.

Two of Twitterrific 6's new themes: Dove and Parakeet

Two of Twitterrific 6’s new themes – Dove and Parakeet

For those of you who want to customize things even more, we’ve added a total of five new colorful themes (two light, three dark) plus three more app icons. There’s also a brand new font available that will totally refresh your timelines: San Francisco Compact Rounded. If you’re feeling especially brave and adventurous, you might find even more customization options by poking around in iCloud Drive – but you didn’t hear it from us! 😉

Twitterrific 6 is a new product. It is free to use with banner ads and occasional purchasing reminders which can be completely removed by subscribing (either monthly or yearly). There are no sneaky free trials here – you have an unlimited time to try before you buy. If you don’t want to subscribe, we also offer a one-time purchasing option that’ll unlock Twitterrific 6 for the duration of its life (Twitterrific 5 had an incredible seven year run!). Scroll through Twitterrific’s development timeline below to see how we got from version 5 to the new and improved version 6.

86 Free Updates, 0 Paid Upgrades

Twitterrific 5's update history - over 6 years of development from 2012 to 2019

There are so many more improvements and bug fixes, including an expanded Twitterrific sticker pack for iMessage, accessibility improvements for Voice Over users, and much, much more. Be sure to visit Twitterrific’s version history page for the entire, huge list of what’s new, then head to the App Store and download Twitterrific 6 for iOS today. Enjoy and thanks for your support!

Head and Shoulders

May 31, 2019

By Ged Maheux

The Iconfactory's Craig Hockenberry towers at Apple's WWDC conference in 2009

I’ve been privileged to know and work with many talented people over the years. People with a drive to succeed and a flare for thinking differently. People who genuinely care about making the lives of other people better, while at the same time pushing you to be better, too. My friend Craig Hockenberry is one such person. Craig’s been a driving force here at the Iconfactory since almost the beginning, and we wouldn’t be where we are today without him.

That’s why I was so pleased when Apple chose Craig for their spotlight series on key developers in the macOS community. Apple’s piece in the Mac App Store touches on the genesis of our flagship Twitter client, Twitterrific, his important contributions to the Twitterverse, and more. Craig would be the first to say that developing an app like Twitterrific is a team effort, so I think it’s also important to give shout-outs to Sean Heber, who has deftly helmed Twitterrific’s development for many years, David Lanham, the talented artist and designer who gave birth to Ollie, Tyler Anderson, who cut his coding teeth on Twitterrific and helped keep Sean sane, and finally Anthony Piraino, whose iconic and design sensibilities put Twitterrific in a class of its own.

On the eve of the launch of Twitterrific 6 for iOS, I’m proud Apple has decided to feature my friend Craig and our small company. It’s taken years of dedication and hard work not only to stay afloat in the wide, vast sea of the App Store, but to succeed where so many others have failed. That’s in no small part due to the amazing talent and experience of our beloved CHOCK. Congrats, Craig!

What to Expect From Marzipan

May 8, 2019

By Craig Hockenberry

It’s clear that this year’s WWDC is going to be a doozy. We’ve written here previously with our thoughts about Dark Mode, now it’s time to talk about iOS apps coming to the Mac.

Of course I’m talking about Marzipan, a technology Apple introduced with few details during last year’s Keynote. We knew that some apps in Mojave used the new technology and that was about it.

Screenshot of the iOS version of Twitterrific running on a Mac

The iOS version of Twitterrific running on macOS thanks to Marzipan.

Thanks to the hard work of Steve Troughton-Smith, we have a much clearer view of what’s happening behind the scenes with application architecture and available APIs.

What I’m going to focus on today is how this new technology will affect product development, design, and marketing. I see many folks who think this transition will be easy: my experience tells me that it will be more difficult than it appears at first glance.

For the past year, I’ve been working on a new product that runs natively on three operating systems: iOS, tvOS, and macOS. As a result, I feel like I can talk with some authority on the differences between these platforms. My biggest takeaway from this project is how different interaction models have a ripple effect throughout a product.

(We’re not ready to talk about this project in public yet, but Patreon supporters are getting sneak peeks.)

A Little Bit of History

Before we get into the interaction details, let’s take a look at tool and framework transitions on the Macintosh. Marzipan may be something new, but it’s certainly not a first.

Macintosh Programmer's Workshop Screenshot

I’m old enough to have been around when the Mac first shipped: in 1984 you could buy some floppy disks to write code in Pascal or 68K assembly code. After a few years, the way you made these revolutionary computer interfaces evolved into MPW, the Macintosh Programmer’s Workshop.

CodeWarrior Screenshot

Fast forward a few years and things had moved on to a new language and tools. Many folks were using CodeWarrior and C++ to build their Mac apps. I developed the Iconfactory’s first software product using this environment.

The modern era then arrived with NeXTSTEP in the year 2000. It brought an unfamiliar language called Objective-C, a new IDE called Project Builder, and awesome new frameworks named Foundation and AppKit. These tools have served the Mac well for many years and even provided a foothold for iOS with UIKit in 2007.

And now a modern macOS toolkit will include Swift, UIKit, and Marzipan. Or, as we like to call it, Chameleon 2.0 :-)

As you can see, the stuff that you use to build Mac apps has changed radically over the past 35 years – but it’s important to note what hasn’t changed during that same period of time. You still use a bitmap display for output with a keyboard and mouse for input. The interaction model has changed, but only slightly. There are enhancements and refinements, like trackpads and gestures, but a Mac is completely usable using nothing but the basic concepts that were laid down by the original team.

It’s All About the Interaction

It’s likely that getting your iOS app to run on a Mac will just be a matter of flipping a switch in Xcode. Steve Troughton-Smith has been converting apps using nothing more than a Simulator build, his marzipanify tool, and a lot of clever tweaks with frameworks.

It will be exciting for a lot of developers, including yours truly, to press that button. But it’s also important to temper this enthusiasm with reality: that build setting is just the first step on a long and complicated road. Good interaction doesn’t come for free.

As you saw above, the Mac has seen a lot of tool and framework transitions. But this is the first transition which involves a large group of developers who don’t have any experience on the platform they’re targeting. A Mac developer moving from CodeWarrior and C++ to Project Builder and Objective-C didn’t have to learn anything new about conventions: they were still on a Mac. That can’t be said about iOS developers who are starting to use Marzipan.

Early iOS interface that took cues from the desktop.

In the early days of the iPhone, there were many apps developed by folks who brought their sensibilities from Windows or the Mac to a new platform. Those apps felt wrong and have largely disappeared because everyone has figured out that different interactions are needed for a small, handheld device. Don’t let the same thing happen when you bring your iOS expertise to a Mac.

If you’ve been developing on iOS for any period of time, you’ve probably had the “flip a switch” experience when starting an iPad app. It’s fairly easy to get things up and running, but then you realize that there are a lot of design and code changes needed for a larger screen. You’ll start reworking things with master/detail views and auto layout constraints. You might even need to adapt your app to support input from a Smart Keyboard.

Look at how many user interface idiom checks you have and you’ll start to get an idea of what lies ahead for a macOS app. If you’re someone who’s decided that an iPad version of your app is too much extra work, you’ll likely think the same thing about all the conditional checks required for a Mac.

Many of the thoughts in this essay got their start while developing a tvOS app: I found that having a common user interface toolkit wasn’t much help. It’s nice to have familiar UIKit items like UIImage, UIColor, and UIButton, but in the end I found that little code was shared between platforms. Some views could be ported directly between platforms, but anything involving a controller was out of the question. Why?

Put simply, the interaction on a TV app consists of six things happening: up, down, right, left, select, and back. Pointing anywhere on screen is not an option: your controller has to guide the customer around as they use these simple interactions. Code to navigate between buttons and collection view items is entirely different. Similarly, UIKit on macOS won’t magically solve your problems when someone wants to use the tab or arrow keys to navigate views in your iOS codebase.

You’ll face similar issues when you encounter a customer who needs to select multiple items by dragging a mouse, open a context menu with the right mouse button, use a keyboard shortcut to make their work quicker, or customize function keys for common actions.

How do you drag a selection when your code assumes that pointing at the screen is to facilitate scrolling? Is a right mouse click like detecting a different finger? Is there going to be a new mechanism for defining keyboard shortcuts and creating items in the menu bar? Will there even be a way to link in Carbon event callbacks?

I don’t know the answers any of these questions, but I can guarantee that these new interactions will require additional work in your app.

It’s also likely that you’ll suddenly find classes like UIResponder a lot more important. Routing events through your app becomes more difficult when they have to pass between multiple view and window instances, a menu bar, and an application delegate.

To get an idea of the scope of the project you’re about to embark on, I would suggest getting a head start by reading the macOS Human Interface Guidelines (HIG). These guidelines have been around since the original Mac, are easy to understand, and provide a valuable reference for every Mac developer.

Screenshot of a macOS popup button

How is this standard macOS control going to work on iOS?

Besides learning what you don’t know, you’ll also get a chance to think about how something simple and familiar on the Mac, like the pop-up button, might be implemented for both iOS and macOS. That simple control doesn’t have any analog on iOS, but someday it will, and you’ll be using it for code on two platforms.

Design Considerations

Coders will not be the only ones affected by Marzipan. As a designer, you’re going to face challenges, too.

The guidelines mentioned above should be your first stop: there isn’t any code and the descriptions often have great visual examples.

The most obvious design element that will change as you move from iOS to macOS is the screen. If you’ve designed for the iPad, you already understand the challenges of a larger display surface and adapting your views as that size changes. It’s not easy work, but an alternative design that’s just “a big iPhone” is highly unsatisfying for a customer.

The Mac alters this scenario slightly because your app is presented in a window that’s resizable: you might be running with the constraints of an iPhone SE one moment and the expansiveness of an iPad Pro the next.

These resizable windows will also let you show more than one view at a time. On iOS, you’re accustomed to owning the entire screen and only having to accommodate for the user’s attention in one place. The Mac, on the other hand, has many applications that are vying for input and output mechanisms.

On macOS the notion of “window focus” is used to highlight anything that’s currently receiving user input. Some of this will be automatic, such as with the window chrome, but you’ll also want to improve the experience in your own views by guiding the user’s actions. If controls aren’t active because they’re in a background window, they’ll need to be de-emphasized.

The notion of “focus” also leads to a less obvious design change: an omnipresent keyboard.

On a Mac, you always have a keyboard and folks have developed many habits that revolve around this input device. With iOS, working with a keyboard is an enhancement, and many apps don’t bother to make use of it. Using Marzipan means you’re adopting a new interaction mechanism that goes beyond pointing at a screen.

Menu screenshot from Sketch on macOS

Since it’s your job to define the user experience, you’ll be responsible for creating items in the menu bar. Apple has many recommendations for menus, but you’ll get off to a good start if your menu items use verbs for actions and adjectives for states.

Think of menu bar items as a way for people to discover capabilities in your app: Mac users often scrub through a new app’s menus as a way to see what can be done. It’s also important to determine the most common actions in your app and assign keyboard shortcuts that will speed up the customer’s work.

Menus may feel a little odd at first: they’re basically a user interface element that’s hidden until needed. As such, it’s easy to neglect this important part of the experience, but your new customers will let you know when it’s not right :-)

The final interaction change you’ll need to consider is that a mouse isn’t a finger. On iOS you’re either touching the screen or you’re not. A mouse pointer has a third state: apps can know when a pointer is hovering over a view. This new capability can greatly increase the usability of your app by highlighting important elements in your interface when the customer’s mouse gets close.

As far as assets are concerned, you’ll have some new graphic files to produce. The most obvious is a Mac desktop icon, which should be similar to, but not the same as, your iOS icon. Utility applications typically get a round icon, while document-based applications get a perspective treatment. Unlike iOS apps, the Mac also has a separate icon for documents that appear on the desktop.

A comparison of Mac and iOS icons done by the Iconfactory

Examples of macOS and iOS icons done by the Iconfactory.

Another thing to be aware of is that Marzipan currently displays your design about 30% smaller than iOS – a 100pt image gets rendered on screen at 77pt. This is done automatically at runtime to accommodate the Mac’s larger perceived size and smaller hit areas. A mouse pointer is more accurate than a finger and needs less room to operate.

Hopefully this will change in the public release so you can specify platform-specific images. If not, you’ll need to ensure that designs with fine details render correctly. Hairlines and other pixel-level drawing are likely to be problematic.

And speaking of pixels, there may be a need to support @1x screens again. Everything on iOS is @2x these days, but you’ll encounter many customers on the Mac who still use a non-Retina display (especially as a secondary monitor.) Yay.

We’ve saved the biggest design challenge for last. It’s who you’re designing for – the person who’s going to use a Mac version of your iOS app.

A Different Kind of Customer

You’ve been creating apps for people who drive automobiles. Now you have a different kind of customer: one who drives a truck. These folks have a wholly different set of expectations for your product.

And rightly so: why use your app on a Mac when all it does is replicate the functionality of their mobile device? Sure, there’s some convenience involved, but giving that customer a more powerful environment plays more towards their wants and needs.

To get an idea of what this type of customer looks like, take a moment to listen to a recent episode of the Accidental Tech Podcast (ATP). The subject in the segment is iTunes, but it could just as easily be about your app.

Minimalism has always been an appropriate goal on an iPhone. Your target audience doesn’t need or want distractions from their basic tasks.

This started to change when the iPad debuted; apps became more immersive because you could do more with a bigger canvas. Now, with a Mac, folks are going to expect even more powerful interactions. Listen to John Siracusa, a guy who knows just a bit about macOS, as he talks about table views and you’ll start to understand your new goals. Let’s call it “unminimalism”.

These folks also form a user community that’s different than what you might have encountered previously. It’s a warm and kind bunch who will become great supporters when you show a passion for their platform of choice. They can also become critics if your efforts aren’t up to snuff.

Keeping two wildly different groups of customers happy with a single app won’t be an easy task, but it’s one that you’re going to be taking on with Marzipan.

Which leads to the final, and most important, topic. How are you going to fund all of this work?

Show Me the Money

Products need to make money or they cease to exist. But if making a Mac app is just a matter of flipping a switch, why should customers pay for that?

It’s my opinion that Universal apps were the worst thing to ever happen for the iPad ecosystem. There’s no way for a developer to recoup the costs for new interactions and the extra work needed for more sophisticated apps. Apple makes it easier for a customer up front by offering a single download, but at the same time they make things worse because a Universal version of the user’s favorite app isn’t financially viable. Apple has few customers who pay directly for their software, so this aspect of third-party products may be a blind spot for the company.

My biggest fear for Marzipan is that Mac apps become a part of a universal download. Nothing could kill my enthusiasm for the project more quickly.

The Future Repeats Itself

At this point, I think it’s clear that this is going to be a long process for both designers and developers. And customers, too.

I think it’s good to look back on the early versions of Mac OS X: how many iterations did the NeXT software go through before it felt Mac-like? It depends on who you talk to, but for me it took a couple of years before this new system felt comfortable.

Early version of Mac software running on NeXT STEP

It was a mess, until it wasn’t.

Along the way, long-time macOS users will lose some things forever. Other changes will be uncomfortable at first, but we’ll adapt, even if things like ⌘N muscle memory hold on for a decade.

But make no mistake, everyone is going to be adapting, even the new kids on the block. And like what you’ve experienced recently with a new programming language, there will be bumps in the road and you’ll find yourself dealing with unexpected changes.

In the end, we’ll have something new and wonderful that we all love.

Hopefully this post has helped prepare you for what lies ahead with Marzipan. Remember that we’re here to help as needed, whether it’s an app icon, assistance with user interface design, or consultation about making great Mac apps. We’ve been doing this stuff since 1997, so let our experience help guide you!

Designing for a Great Cause

May 6, 2019

By Webmaster

James Dempsey performs at the App Camp for Girls WWDC live event in 2018

The amazing folks over at App Camp for Girls have been hard at work preparing for Apple’s World Wide Developer Conference, and we wanted to help get the word out. They’re an incredible organization that inspires and empowers girls, transgender, and gender nonconforming youth to pursue careers in technology. Helmed by some of the most talented and committed people in the technology community, App Camp for Girls is making a difference in the lives of kids, and we fully support their vision of gender equality in the tech industry.

One way you can support them is to grab a ticket for LIVE near WWDC, a James Dempsey and the Breakpoints concert benefitting App Camp for Girls. The show will be Wednesday, June 5th from 7pm – 11pm in San Jose, and features a musical band of techies, nerds, and community luminaries performing a full concert of humorous, original, programming-oriented songs. You don’t need a WWDC pass to attend, but you will need a ticket and they’ll sell out fast, so don’t wait – this is one party you don’t want to miss! The group hopes to raise $25,000 to support future camp events, a worthy goal.

Clarus the Dog Cow in neon saying

Attendees can also snag a snazzy App Camp for Girls enamel pin that we designed especially for the occasion! With a limited run these pins will surely become coveted collector’s item and are just another reason to attend this night of fun.

Finally, there are still three days left to pick up your exclusive Owl-tline T-shirt from Cotton Bureau. Proceeds go to support App Camp for Girls, so what other great reason do you need? Pick up an event ticket, order a shirt, and help bolster the gender diversity of tomorrow’s tech industry.