![\"Photo](\"https://zmknox.com/resources/2025.jpg\")
Today is the Transgender Day of Visibility, and, for the first time, I am visible.
\n\nHi, I’m Zoe 👋. I use she/her pronouns, and I’m a trans woman.
\nI’m also a software developer and big computer nerd. If you don’t know me, I build JavaScript tools for work, have made a few neat websites on the side, dabbled with some iOS apps here and there, and listen to a bunch of technology podcasts. And I don’t expect any of that to be changing any time soon.
\n
It’s taken me a long time to get to this point, and there’s still plenty that I have yet to do, but I’m so glad that I feel ready to be public about this important part of myself. I’m not gonna get all philosophical with this coming out post[1], because frankly I don’t really have much more to say beyond “hey I’m a girl!”. But it really is freeing to not have to to hide a part of me away anymore.
\nThis is, unfortunately, not a particularly great time to be trans in the United States[2]. Our government is pushing order after order to strip us of our rights and treat us as second class beings, and we cannot let this stand. We must be visible and stand against this bigotry. If you’re cis, please be loud in support of trans folks, we really need it.
\nNext time I post here[3] I’m sure I’ll be writing about computers again, but thanks for reading this very personal note. And an extra special thanks to my friends and family who have been so supportive of me throughout my transition. Y’all are the best.
\n🏳️⚧️❤️
\nP.S. If you’re trans or questioning your gender, feel free to send me a message if you wanna chat. I’m always happy to talk with other trans folks. (I know this can be especially scary in the early stages—I’ve been there—but I promise I don’t bite). We have to support each other!
\nIf that’s what you’re looking for, check out Abigail Thorn’s incredible coming out video from a few years ago. ↩︎
\nIf you’re interested in keeping up with trans news, legislation, rulings, etc, I highly recommend following Erin Reed’s site Erin In The Morning. She and her team do an incredible job at following and reporting on trans topics (and also helped me find a trans kid to buy Girl Scout cookies from). ↩︎
\nSpeaking of “here”, you can reach this site by visiting zoeknox.com too! You’ve actually been able to do that for a few months I think. ↩︎
\nHello and welcome to my NEW new website. If everything goes well, it should look almost exactly the same[1].
\nAround nine years ago, I set this website up with Jekyll and GitHub Pages. Since then, it’s gone to a new host (I’m currently hosting it using Cloudflare Pages), switched primary domain names (though most old links should still redirect), and now is undergoing a brain transplant. From Jekyll to Eleventy!
\n\nSo here’s the deal: Jekyll is a great tool, but I could basically use it at the surface level. I did some cool stuff, like making my projects & (secret) TV pages data driven and adding “link post” support to this blog, but those were all playing within the sandbox of Jekyll and Liquid as provided. So when the sandbox broke, I panicked.
\nLast month, I thought to add that nice new little footer text you see down there after my copyright and privacy link. I tried to run a build locally, and my Ruby configuration complained that I had something messed up. I threw out the lockfile (as I would do in a Node.js project) and started over, and things seemed OK… until I went to publish those changes. Cloudflare complained about my configuration and wouldn’t build it.
\nAnd look, it’s probably a silly little issue that anyone who knows Ruby could fix in like 15 minutes or less. But I know nothing about Ruby. I write JavaScript and TypeScript for my day job, and some Swift here and there—but I’ve never even touched Ruby (as much as some of my Rails convert friends may have wanted me to in college).
\nI ultimately went with using Eleventy as my Jekyll replacement for two reasons. First, it’s JavaScript based, which means I, a professional JavaScript developer, am much more likely to be able to debug anything that may go wrong. Second, my internet pal Robb Knight has been singing Eleventy’s praises for a while now. Robb seems pretty smart, so I took his recommendation.
\nMy experience with configuring my site has been mostly smooth[2], but I had to change a bit about how I think about the site. Eleventy is a more minimal in its base package. It expects you to extend it with separate npm packages if you need extra functionality, like special markdown parsing. But extending base Eleventy is actually quite easy.
\nFor example: On my old site, my RSS and JSON feeds were made using files with liquid templates. It kind of felt like a hack, but it worked. Thankfully, with Eleventy, there’s a better way. I can use Eleventy’s RSS plugin to have it generate a proper feed for me with a few settings in my configuration file.
\nMy site doesn’t yet do much particularly complicated with these abilities yet, since my initial priority was just “make my website work again”. But I’m excited to have the opportunity to have more capability looking forward.
\nI haven’t really used Eleventy enough to truly be able to give it a rating or recommend others move their sites over to it, but it seems pretty solid so far. If you’re looking for a new static-site generator for your site, and you feel comfortable with JavaScript, it’s definitely worth a look.
\nI’m sure I’ll have at least one more blog post here this year. But in the meantime, thanks for checking out my new website!
\nI did make a couple of design tweaks. I tweaked the navbar to use the previously mobile-only layout everywhere, and made my current projects show one entry per row. But it’s like 95% the same. ↩︎
\nThe worst issue I ran into was an issue where all the dates rendered on my website were off by one. This was because it assumed a date without atime was midnight UTC. Since I live in the US, that meant that the value it rendered was the date prior, as it wanted to render a local date. Eleventy lists this as a “common pitfall”, but I tend to think it’s a bad default. I have no idea what the time zone is of the Cloudflare server that will render my site. The render behavior of my local build should not be different from my server based on the time zone of my local machine. ↩︎
\nI have low vision. A kind you can’t really correct for with glasses or contacts. I also bought Apple Vision Pro at launch. Why would I do this? Well because I’m a nerd who wants to see the future, but also because I was fascinated to see how Apple would handle accessibility for this new product. Apple’s track record on accessibility in the past decade has been stellar[1], in my opinion, with their teams adding powerful options every year and ensuring every new platform has accessibility support built in from the start.
\nAfter watching Apple’s WWDC23 session on visionOS accessibility, I knew accessibility on visionOS was an important point for them. But even after consuming as much information on the platform as I could, I knew I had to try it for myself to know the answer to the important question: how well does it work for me?
\n\n![\"A](\"https://zmknox.com/resources/vision-accessibility/accessibility-settings.png\")
n.b. Before I begin, I want to make clear that these are only my impressions. There are many different ways vision impairments and disabilities can affect how someone experiences technology and the world, and I can only speak to my own experiences.
\nOn any computer system, how you interact with it is critical, and it’s one of the things that sets Apple Vision Pro apart from other devices (and even other VR headsets). Apple’s tech specs page describe input as relying on “Eyes, Hands, and Voice”, so let’s start there.
\nThis is probably the biggest input innovation in the product—you just look directly at what you want to select! (I recommend watching Apple’s guided tour video if you aren’t familiar with how this works). But that paradigm can quickly break down with various eye conditions. One aspect of my vision is nystagmus, or uncontrollable eye movements. I generally don’t actively notice this, apart for possibly having more trouble focusing quickly on some things at times. But I could very quickly tell that it would cause Apple’s eye tracking system to work less than ideally (Apple does specifically call out that users with nystagmus may have issues).
\n![\"A](\"https://zmknox.com/resources/vision-accessibility/eye-setup.png\")
Some things work great. I can very easily select an app from the Home View or scroll the massive Runestone window that I’m typing these words into right now. But it doesn’t take long to encounter issues. For me, that generally involves having many selection targets close together. That includes many toolbars (eg getting to the “Tab Overview” button in Safari), the virtual keyboard (when using look-and-tap), and even, at times, the close window button.
\n\nThat said, it’s far from unusable. I can still generally get around most things OK, but it’s clear that some interactions are harder for me than they are for others.
\nI also generally wear tinted contact lenses to help control the amount of light going into my eyes[2]. When purchasing Apple Vision Pro, you’re presented with a series of questions about your vision and whether you wear glasses or contacts. One of these asks about whether you use contacts with a tint. If you say yes, it tells you that you can’t use these with Apple Vision Pro. But I’ve found that’s not entirely true.
\n![\"A](\"https://zmknox.com/resources/vision-accessibility/purchasing.png\")
I’ve tried using my Apple Vision Pro both with and without my contacts, and can get the eye tracking to work fine with either… with a catch. Using my calibration from one configuration doesn’t work properly with the other (I could launch some apps from the Home View, but not much else). So if I last used it with my contacts, I need to re-run eye setup to use it without them. Luckily, there’s a shortcut for this. Quadruple-clicking the Top Button will start eye setup, making it easy to get into without having to dive into Settings. I do wish they’d allow me to save two eye setups (a feature they already provide for users who may use Apple Vision Pro both with and without ZEISS Optical Inserts), but re-running setup isn’t a huge pain.
\nInterestingly, Optic ID works with either configuration without need for re-registration, which was a relief for me, as it means things protected by the secure enclave (including my Persona) don’t need to be reset.
\nEye tracking is good and all[3], but you generally only use your eyes as a pointer, with your hands acting as the “mouse button”. And I’m glad to say I’ve had effectively no issues there, save for having to remember not to accidentally have my finger and thumb touching and to have my hands in view of the cameras.
\nIt’s also worth noting that, for almost all visionOS UI, you can also directly touch any UI element if it’s close enough to you. This often isn’t practical, as most windows will be further than arm’s reach away, but it can be handy for a webpage or iPad app with odd tap targets. Most users will probably use this most often with the virtual keyboard, but it’s always worth keeping in back of mind in case something can’t be reached with the typical look-and-tap approach.
\nSiri has nearly all of the same abilities it has on iPhone and iPad, but it is extra useful in Apple Vision Pro to control windows. You can tell Siri to open or close an app, or even to get rid of everything in your view. This is extremely convenient, and really helps when navigating the system. I will frequently ask Siri to open something like 1Password or Safari if I need to check something quickly while in the context of another app.
\n![\"A](\"https://zmknox.com/resources/vision-accessibility/siri.png\")
Additionally, dictation is built deep into the OS. Nearly every search field has a microphone which, if you stare at it long enough, will let you speak your query into it. This is a pretty neat idea, but it seemed to sometimes stop listening if I looked away soon after it started listening to me—resulting in the dictation session being cancelled. That may just be some 1.0 bugginess, though.
\nBut that’s not all! The virtual keyboard, as well as the QuickType bar that hovers above physically connected keyboards, also has a dictation button, and that one acts as a toggle. Tap it once to start dictation, and again to stop. This works great, and exactly how you would expect it to.
\nSo that’s what you have out of the box, but Apple provides many alternative ways to interact with the system as well. Not all of these are specifically targeted towards aiding those with vision disabilities, but they all felt worth investigating to compare the benefits and drawbacks of each.
\nThis isn’t even marketed as an accessibility feature. Connecting a Bluetooth keyboard and/or Magic Trackpad allows you to control apps just as you would an iPad.
\n![\"Photo](\"https://zmknox.com/resources/vision-accessibility/keyboard-trackpad.jpg\")
I find a physical keyboard critical for writing anything longer than a quick search, password, or web address. A trackpad is probably less important, but is still nice to have when managing text selections or interacting with iPad apps that don’t scale as well. It does completely mitigate my eye tracking issues, since I can directly select a control with my trackpad if needed. But, of course, using either a keyboard or trackpad requires you have the desk space to accommodate these peripherals, which may not be true if using the device in a more relaxing environment like lying on the sofa.
\nEverything you know about how keyboards and trackpads work on iPad transfers to Apple Vision Pro. You can hold Command to get an overlay of keyboard shortcuts. You can use Command-Space to open Spotlight (which is also accessible via Control Center). The trackpad cursor will jump from element to element (though less often than on iPad, as elements tend to be larger). It all just works.
\nThe downside, of course, is that you now have to deal with a separate keyboard and trackpad. Do you keep them on a spare desk? Do you pack them with you when you take Apple Vision Pro on the go? It’s a hassle.
\nWhen your physical trackpad isn’t nearby, you can use Pointer Control. Pointer Control allows you to control a virtual cursor, much like the one you can control with a trackpad, using different parts of your body.
\nWith both of the hand-related options, you can also add a ray going from your hand to the cursor, which can aid in keeping track of where the cursor is.
\nNone of these options are as “magical” or quick as using eye tracking, but they can be handy to toggle on if I find myself in an app with a harder-to-use interface. Ultimately, Pointer Control is probably the most useful accessibility feature for those with nystagmus.
\nA screen reader in a device designed around vision? You bet. VoiceOver reads content and information about UI elements aloud, relying on many different hand gestures to perform different actions without needing to see the displays[4]. You can tap your right index finger to move to the next element, your right middle finger to go back to the previous element, and your left index finger to select the highlighted element. You can also hold fingers on one hand while tapping with the other to switch apps or use the Rotor (a concept borrowed from iOS allowing you to quickly change the way VoiceOver steps through elements). Additionally, you can enable an “exploration mode”, allowing you to move your head to find different visible UI elements. VoiceOver also uses spatial audio to help you locate where the element or app that is speaking is in your physical space.
\nWhile I think it’s extremely impressive that they were able to ship VoiceOver on such a different product with zero physical input devices, I feel it may be a bit fiddly, at least for a newcomer. When I tried it, I found myself getting a bit lost. I was often using the wrong gesture and going somewhere I didn’t intend. This was particularly notable when multiple apps were open. Trying to figure out what I was controlling and why focus was moving around between apps felt pretty confusing at times. It certainly feels very powerful, however, and I imagine somebody, given enough time to learn how to best utilize it (and maybe a few software updates on Apple’s end to smooth out some of the rough edges) could make great use of VoiceOver in their workflows.
\nI don’t personally use VoiceOver much at all on any platform, as my vision isn’t poor enough to require it, but I try to stay proficient at navigating the system with it. It completely changes the way you interact with your device, whether that be a Mac, iPhone, or Apple Vision Pro, and using VoiceOver helps me to think about app design in a more inclusive way.
\nOne potentially incredible feature of VoiceOver that I couldn’t seem to get working is “describe passthrough” which, if Apple’s descriptions are to be believed, will describe with spoken words what you are looking at in the real world. You can do this on iPhone in the Magnifier app, but having that ability in a head-mounted display would be truly next level. I hope this feature gets working in future software releases.
\nMuch like on iPhone, iPad, and Mac, Voice Control allows you to select effectively any UI element with your voice. And it works great on Apple Vision Pro too. You can call out “tap Search” or “close window” and it will promptly do so. You can also tell it to “show names” of selectable elements so you know what you can tell it to tap, “show grid” to tap a specific region with accuracy, or “show numbers” to see everything selectable even if they don’t have good accessibility identifiers. This is an incredibly well-built system that, while built for those with mobility issues, can also be useful if eye tracking isn’t working as well, as you can simply tell it to tap the button you intend to select[5].
\n![\"A](\"https://zmknox.com/resources/vision-accessibility/show-names.png\")
![\"A](\"https://zmknox.com/resources/vision-accessibility/show-numbers.png\")
![\"A](\"https://zmknox.com/resources/vision-accessibility/show-grid.png\")
I don’t use Voice Control all that often, but it can be a nice alternative in some situations, particularly when I’m in a dim environment where the cameras have more trouble tracking my hand movements.
\nThis is a fun one. You can assign various actions to different sounds you make. You can open Control Center by making a “P-“ sound, or the Home View by making a “click”. This is a clever idea, but not one that I could seemingly get working. It couldn’t seem to detect the sounds I was making.
\n![\"A](\"https://zmknox.com/resources/vision-accessibility/sound-actions.png\")
Many of these input options—as well as many output options I discuss later on—have situational use for me. Useful to get at a particularly tricky to tap button or switch, for example. This is where the Accessibility Shortcut comes in handy. Much like on iPhone with a triple tap of the side button or a Mac with a triple press of the Touch ID/power button, triple pressing on the Digital Crown can either toggle a single accessibility setting or, if multiple are selected, present a list of settings to toggle on or off.
\n![\"Screenshot](\"https://zmknox.com/resources/vision-accessibility/accessibility-shortcut.png\")
visionOS allows you to maneuver this list by turning the Digital Crown, making it usable even when your current input method is failing for you.
\nInput is only half of the story. Just as important is making sure I can actually make out everything that is being displayed around me.
\nThere are two kinds of apps you’ll encounter on Apple Vision Pro: compatible iPhone or iPad apps and native visionOS apps.
\nCompatible apps, which live in a special folder in the Home View apart from native apps, use their original iOS light mode visual style. Because these apps haven’t been updated specifically for Apple Vision Pro, their touch targets often feel a bit small, and may not have any highlights to track where you’re looking.
\n![\"A](\"https://zmknox.com/resources/vision-accessibility/apple-podcasts.png\")
By contrast, native visionOS apps have an all new visual style. They generally have a translucent “glass” background with light text, keep toolbars in separate floating “ornament” views across the top or bottom, put their tabs into a strip along the side, and have broader spacing between UI elements. These apps not only look fantastic, but also feel so much better than compatible iPad apps with their larger tap targets.
\n![\"A](\"https://zmknox.com/resources/vision-accessibility/apple-music.png\")
On my other devices, I almost always use a “dark mode” when available, putting light text on a dark background. But on visionOS, regardless of app type you’re using though, there is no concept of light or dark mode. This means that you’ll forever be using iOS apps with a bright white background & dark text and visionOS apps with a darker translucent background & light text. Going between these feels quite jarring to me.
\nI suppose I can understand why, if they are only going to pick one style for compatible apps, Apple would chose light mode as the only visual style. Even as a dark mode user, I still think of light mode as the “canonical” visual style on iOS. But in use it just feels out ofqqq place to me. This was made even clearer to me when I turned on the manual overrides available in apps like Overcast, Ivory, and Discord to use their dark modes anyway. This made those apps immediately feel better to use alongside native apps for me. I really hope Apple reconsiders this design decision in the future.
\n![\"A](\"https://zmknox.com/resources/vision-accessibility/overcast.png\")
Beyond these basics, visionOS also provides many options to adapt its interface to be easier to view, no doubt stemming from its lineage to iOS and iPadOS which have had stellar support in this area for years.
\nJust like on iPhone and iPad, you can set your system-wide text size as big as you want, or even smaller than default if you prefer. This allows me to make sure everything is readable without needing to get as close to windows, which is particularly important in a headset where the focal plane is far enough out that getting too close to virtual objects makes them blurry[6].
\n![\"Comparison](\"https://zmknox.com/resources/vision-accessibility/text-size.png\")
visionOS text size stops are at different scales than iOS’ sizes. The steps on iOS from 100% to 150% are 100-110-120-135-150%, while visionOS has steps at 100-105-115-125-130-150%. The largest accessibility text size on Apple Vision Pro is only 200%, while iPhone scales all the way to 310%. I also personally use a higher absolute text size option in Apple Vision Pro then I do my iPhone (Either 130% or 150% on Apple Vision Pro vs 120% on iPhone). Given both of these, I would definitely be wary of recommending this product to anyone who uses one of the larger accessibility text sizes on iPhone or iPad.
\nIn many apps, especially those written with modern APIs like SwiftUI, text size scaling isn’t much of a concern at all. But text being cut off or mismatched in size can definitely be an issue in some apps. This is nothing new, as you can see many of these same issues on iOS with high enough text sizes, but is worth keeping in mind if you’re planning on using a larger text size. I notice these issues in Apple Vision Pro a lot more when using compatible iPad apps.
\nYou can also set text size per app, but, unlike iOS, you can only do this deep within the accessibility section of Settings, not with the Text Size control in Control Center. I would love to see this flow be as easy as on iPhone in the future (FB13629357).
\nOn iPhone and iPad, you can change the UI scale of all elements of your device’s display using “Display Zoom”. Window Zoom is the same concept, but, due to the nature of the device, only scales digital windows—not your physical space. You can select between four sizes, from small to extra large. I use the extra large size which, while it may mean I can fit fewer windows in my view, makes them much more visible to me.
\n\nI find this setting to be much more useful than the equivalent on iPhone and iPad, where I prefer to only change the text size. I think this mainly comes down to how windows feel. A visionOS window is sort of similar to a whole display in physical space. And, much like how I have a 65-inch TV in a space where many other folks may have only gotten a 55-inch, the extra size helps.
\nYou can also enable a setting to allow you to individually scale any window using a two-handed pinch. This feels incredibly sci-fi, and can be helpful if something is just a bit too small for you.
\n\nTo aid in content readability, this setting makes the glass background of visionOS windows darker and more opaque.
\n![\"A](\"https://zmknox.com/resources/vision-accessibility/increase-contrast.jpg\")
For me, this doesn’t usually make a huge difference, but can be helpful for dark colored text on some backgrounds (particularly red destructive actions in context menus). I tend to leave this off to keep a standard visionOS aesthetic, but I keep it in my Accessibility Shortcut just in case.
\nMuch like on tvOS, it can sometimes be a bit hard to tell where your focus is. To accommodate this, you can enable a setting to add a more prominent highlight around the currently focused UI element. This doesn’t show for every UI element in visionOS, but it shows on most buttons, tables, and other controls.
\n![\"Comparison](\"https://zmknox.com/resources/vision-accessibility/increase-focus-state.jpg\")
This option does have the side effect of making some parts of the interface a fair bit uglier. The virtual keyboard, for example, does not play nice with the focus state highlight at all.
\n![\"Screenshot](\"https://zmknox.com/resources/vision-accessibility/bad-outline.png\")
Another classic Mac and iPhone accessibility setting reimagined. Zoom gives you a virtual head-locked magnifying glass[7] to view digital content through. You can scale the zoom level using the Digital Crown, or move the window around in your view. This can be useful to view or interact with very small UI elements, particularly in compatible iPad apps.
\n![\"Screenshot](\"https://zmknox.com/resources/vision-accessibility/zoom.png\")
I don’t find myself using zoom on Apple Vision Pro nearly as much as I do on my iPhone or iPad, as there are more opportunities to make the windows themselves larger instead.
\nOne interesting quirk of Zoom is that it only zooms digital content, not passthrough. So you can’t use it as a physical magnifying glass. This feels really strange at first, since the digital windows are otherwise anchored incredibly well in your real world space.
\nThis is much less relevant for most use of this device, but is still an important output. Apple Vision Pro can mirror a view of what the wearer is seeing to any compatible AirPlay receiver, iPhone, or iPad. This allows you to show others what you’re experiencing. And, while not designed as an accessibility feature, mirroring your view could be helpful if you, as the wearer, need assistance in dealing with the digital content in front of you.
\n![\"A](\"https://zmknox.com/resources/vision-accessibility/view-mirroring.png\")
Beyond all these options, many of the same settings from iOS remain on visionOS. You can add a color filter to both digital content and passthrough. You can invert colors on all digital content. And you can ask the system to reduce motion. All in all, a very complete accessibility package.
\n![\"A](\"https://zmknox.com/resources/vision-accessibility/classic-invert.png\")
I wrote much of this piece while in Joshua Tree using the fabulous Runestone text editor, using a connected Magic Keyboard and referring to my notes previously made on my iPhone in Apple Notes. I had the Apple Music miniplayer to my right, Discord to my left[8], and a Widgetsmith clock floating up in the sky behind Notes. I was skeptical that I could actually use this device for productive tasks, but after this experience I know I absolutely could. I don’t know if I want to do my 40-hour-a-week software development job while wearing such a heavy thing all day, but it’s fantastic for tasks like writing a blog post.
\n![\"Screenshot](\"https://zmknox.com/resources/vision-accessibility/behind-the-curtain.png\")
Is it perfect? Certainly not. I hit a lot more rough spots than many other users would. But it didn’t catastrophically break down for me either. And compared to the competition, Apple Vision Pro is vastly more accessible. On Meta Quest, you can change the text size of system apps, but that’s about it. Many games and apps on that platform simply don’t accommodate those who may need larger text or views, and that system doesn’t provide any accommodations to zoom or scale third-party content. Apple Vision Pro not only provides accessibility settings that can affect the content of third-party apps, but also offers additional options to allow users to interact with apps that are still tricky to use despite those accommodations. I’m incredibly impressed with the amount of accessibility functionality they shipped on day one.
\nSo I didn’t return it. I’m very excited to see how this brand new platform[9] will evolve over the coming months and years.
\nBefore publishing, I came across this short Mastodon thread from Peter Saathoff-Harshfield describing their own experiences with trying the accessibility features with Apple Vision Pro during an in-store demo which, as they have very different vision disabilities than me, were different from mine. I recommend you check it out if you want another perspective on visionOS accessibility.
\nIf you’re curious about the history of Apple’s early accessibility efforts, I highly recommend listening to Shelly Brisbin’s 36 Seconds That Changed Everything documentary about that very topic. ↩︎
\nMy contacts also have a not-super-strong prescription, but I don’t use any optical inserts, as I already go without my contacts many days, mainly when at home, anyway. ↩︎
\nYou can actually control Apple Vision Pro with only your eyes if needed using Dwell Control (an accessibility feature I’m not covering here as it, by design, assumes you have good vision) ↩︎
\nVoiceOver really falls into both the input and output sections, as it radically changes both. I chose to put it with the “inputs” as that is where VoiceOver felt most different to its counterpart on iOS for me. ↩︎
\nI also find Voice Control useful when I’m under the covers of a warm blanket and don’t want to take my arm out to tap something on my iPad. Simply tell Siri to turn voice control on and then tell your device what to tap! ↩︎
\nI find Apple Vision Pro to be better in this regard than Meta Quest 3, allowing you to get a bit closer without issues. But it’s definitely still noticeable. I find that visionOS elements start to get a bit blurry closer than about an arm’s length away from me, though don’t get unusably blurry until you’re a fair bit closer. ↩︎
\nYou can also zoom your entire view of digital content, but I find this fairly disorienting. Making the window the default was the right call. ↩︎
\nThe Discord iPad app on Apple Vision Pro is Not Great. It doesn’t do much at all for highlighting where you’re looking to select, and has issues with the media picker. But I’m still glad it exists so I can keep up with things while wearing the device. ↩︎
\nI of course followed Apple’s Developer guidelines on how to refer to Apple Vision Pro in this piece 🙃 ↩︎
\nIt’s time for a new year and so, inspired by an initiative spawned by the Hemipsheric Views podcast and further expanded by Robb Knight for folks to share their default apps, I thought I’d share a default app list of my own! This is primarily focused on stuff I use outside of my actual job, which also means my list is extremely iPhone and iPad focused. I have a personal Mac, but I use it shockingly little as of late.
\n\n📨 Mail Client
\n📮 Mail Server
\n📝 Notes
\n✅ To-Do
\n📷 iPhone Photo Shooting
\n🟦 Photo Management
\n🎞️ Image and Vector Editors
\n🎬 Video Editor
\n🎧 Audio Editor
\n📆 Calendar
\n📁 Cloud File Storage
\n📖 RSS
\n🙍🏻♂️ Contacts
\n🌐 Browser
\n💬 Chat
\nI will basically use whatever app I need to to reach folks
\n\n🗣️ Social apps
\n🔖 Bookmarks
\n📑 Read It Later
\n📜 Word Processing
\nEqual opportunity word processing!
\n📈 Spreadsheets
\n📊 Presentations
\n🎵 Music
\n🎤 Podcasts
\n🔐 Password Management
\n📋 Clipboard Manager
\n🧑💻 Code Editor
\n⌨️ Terminal
\nAnd that’s my list! I hope you found something interesting in the list. And be sure to check out Robb’s web page which links to everyone else’s app defaults.
\n", "date_published": "2023-12-30T17:00:00Z" } , { "id": "https://zmknox.com/2021/08/building-a-donation-tracker-widget/", "url": "https://zmknox.com/2021/08/building-a-donation-tracker-widget/", "title": "Building a Donation Tracker Widget with Scriptable", "content_html": "Every year, coinciding with Childhood Cancer Awareness month, the Relay FM podcast network does a “Podcastathon” to raise funds for St. Jude Children’s Research Hospital. (You can donate now at stjude.org/relay!)
\nWith many donation milestones and incentives along the way to their goal, many community members are stepping up to make donation trackers. My friend Matt VanOrmer made a special command for his FeedbackBot in the Relay FM Members Discord and an iOS widget in Python using Pyto. I decided to take on the challenge of making my own version of Matt’s widget using JavaScript with Scriptable. Scriptable allows us to build real iOS user interfaces, including widgets, by writing JavaScript directly on device, and seems like the perfect tool for this job.
\nLet’s get started.
\n\nRelay is using Tiltify to track their donations. Luckily for us, Tiltify has APIs that we can use to access data on campaigns.
\nHere’s how we’re making the request with GraphQL:
\n![special command for his FeedbackBot](\"https://zmknox.com/resources/donation-widget/feedbackbot.jpg\"){kind=link}
const req = new Request('https://api.tiltify.com');\nreq.headers = { \n 'Content-Type': 'application/json'\n};\nreq.method = "POST";\nreq.body = JSON.stringify({\n\t"operationName": "get_campaign_by_vanity_and_slug",\n\t"variables": {"vanity": "@relay-fm", "slug": "relay-st-jude-21"},\n\t"query": `query get_campaign_by_vanity_and_slug($vanity: String, $slug: String) {\n campaign(vanity: $vanity, slug: $slug) {\n id\n name\n slug\n status\n originalGoal {\n value\n currency\n }\n team {\n name\n }\n description\n totalAmountRaised {\n currency\n value\n }\n goal {\n currency\n value\n }\n avatar {\n alt\n height\n width\n src\n }\n milestones {\n id\n name\n amount {\n value\n currency\n }\n }\n }\n}`\n});\nlet body = await req.loadJSON();\nWithin our GraphQL query, we’re requesting many fields including the campaign’s name, its goal, how much has been raised so far, and any milestones set along the way to the goal. This API request returns to us a JSON object that mimics what our GraphQL query looks like:
\n{\n "data": {\n "campaign": {\n "avatar": {\n . . .\n },\n "goal": {\n "currency": "USD",\n "value": "333333.33"\n },\n "milestones": [\n {\n "amount": {\n "currency": "USD",\n "value": "20000.00"\n },\n "id": 127775,\n "name": "Myke and Stephen attempt Flight Simulator again"\n },\n . . .\n ],\n "id": 121745,\n "slug": "relay-st-jude-21",\n "status": "published",\n "team": null,\n "description": ". . .",\n "totalAmountRaised": {\n "currency": "USD",\n "value": "19065.66"\n },\n "name": "Relay FM for St. Jude 2021",\n "originalGoal": {\n "currency": "USD",\n "value": "100"\n }\n }\n }\n}\nNow, we can use this data to build a widget…
\nScriptable lets us build widgets as a list of elements, declared one after another. Let’s start by creating the ListWidget object and set a gradient. Scriptable’s LinearGradient class allows us to build a more vibrant background. Here, I’m making a gradient of two colors (each set by their RGB hex code), and setting its location to run top to bottom:
const primaryTextColor = new Color("#efefef");\n\nconst widget = new ListWidget();\nwidget.setPadding(8, 15, 8, 10);\n\n// widget background\nconst gradient = new LinearGradient();\ngradient.colors = [ \n new Color(`#dcb748`),\n new Color(`#d6aa29`)\n];\ngradient.locations = [0.0, 1];\nwidget.backgroundGradient = gradient;\n\nwidget.url = "https://stjude.org/relay";\nNow we can start adding elements to our widget. Let’s add a big title using the name we got from Tiltify. We can set its text as well as a few variables like color and font style. Additionally, let’s add a spacer element after the text to keep our widget looking nice:
\nconst titleText = widget.addText(body.data.campaign.name);\ntitleText.textColor = primaryTextColor; // primaryTextColor set in earlier code block\ntitleText.font = Font.boldSystemFont(24);\n\nwidget.addSpacer(8);\nAnd finally we get to the good stuff: the actual donation total! Lets add a text element which shows both the total so far as well as the current campaign goal. Tiltify gives them to us as ready-to-go strings, but I’ve converted them to numbers here and back using toLocaleString() to get proper comma separated number formatting:
\nconst soFar = parseFloat(body.data.campaign.totalAmountRaised.value);\nconst total = parseFloat(body.data.campaign.goal.value);\n\nconst amountText = widget.addText(`$${soFar.toLocaleString()} / $${total.toLocaleString()}`);\namountText.textColor = primaryTextColor;\namountText.font = Font.heavyRoundedSystemFont(20);\n\nwidget.addSpacer(6);\nBut I think we can do better than just text. Why not add a progress bar to visually show the donation total?
\nTo render our progress bar, we need to programmatically create an image to visualize the donation total. Let’s make a function that will handle this creation.
\nThis function will use a DrawContext to handle the layout of our visual elements. These are done in absolute points, as opposed to stacking vertically like ListWidget. Here, we’re creating two rounded rectangles. The first, bgPath, will fill our entire width and height as specified, with rounding at about half the height. The second, fgPath will only be as wide as the percentage of donations that have been received towards the campaign’s gaol. We’ve placed these bars such that fgPath is drawn in front of bgPath, which will give us a nice looking progress bar:
const width = 320;\n\nfunction createProgressBar(total, soFar, height, showPercentage = false) {\n const context = new DrawContext();\n context.size = new Size(width, height);\n context.opaque = false;\n context.respectScreenScale = true;\n \n // bar background\n context.setFillColor(new Color("#48484b"));\n const bgPath = new Path();\n bgPath.addRoundedRect(new Rect(0, 0, width, height), height / 2, (height / 2) - 1);\n context.addPath(bgPath);\n context.fillPath();\n \n // bar foreground\n context.setFillColor(new Color("#00b100"));\n const fgPath = new Path();\n fgPath.addRoundedRect(new Rect(0, 0, (width * soFar)/total, height), height / 2, (height / 2) - 1);\n context.addPath(fgPath);\n context.fillPath();\nTo finish off the progress bar, let’s add a text label to, optionally, show the percentage raised as as string. We can overlay this on top of the progress bar for a cool look. The text drawing functions for DrawContext are similar to what we used when adding text to our ListWidget, but do have some of their own syntax to deal with the positioning.
if (showPercentage) {\n const percentage = ((soFar / total) * 100).toFixed(2);\n let xPos = (width * soFar)/total + 5;\n // if over 70%, show in foreground area\n // to ensure that it doesn't overflow the display\n if (percentage > 70) {\n xPos = (width * soFar)/total - 55;\n }\n\n context.setFont(Font.semiboldRoundedSystemFont(14));\n context.setTextColor(primaryTextColor);\n context.drawText(`${percentage}%`, new Point(xPos, (height / 14)));\n }\n\n return context.getImage();\n}\nFinally, lets add our progress bar image to our widget:
\nconst progressBar = widget.addImage(createProgressBar(total, soFar, 20, true));\nprogressBar.imageSize = new Size(width, 20);\n\nwidget.addSpacer(4);\nWith that, you now have a fully functional widget. Let’s take a look:
\n![\"A](\"https://zmknox.com/resources/donation-widget/widget-basic.jpg\")
But our large widget is looking a little empty. What if we could add some milestone progress bars to fill that up?
\nTiltify gives us the campaign’s milestones as an array, which allows us to create a progress bar for each milestone by simply looping through it. We can also allow the user to choose how many milestones are displayed by using the widget parameter field:
\n// only show as many milestones as the user requests\n// (1 looks good on a medium widget, 3 or 4 on a large)\nlet maxMilestones = args.widgetParameter;\nlet milestonesDisplayed = 0;\n// progress bars for milestones\nfor (let milestone of body.data.campaign.milestones) {\n if (maxMilestones != undefined && milestonesDisplayed >= maxMilestones) {\n break;\n }\nThe rest of this loop should look pretty familiar to what we were making before: we’re adding text and progress bars to our widget. Here, though, we’re combining two text elements into a stack, which allows us to place the milestone name side-by-side with its percentage in a different font. We’ve also added a conditional such that we’re only adding milestones with less than 100% progress. This ensures we’re only showing milestones that are relevant to the current total:
\n // calculate milestone percentage\n const milestoneTotal = parseFloat(milestone.amount.value);\n const percentage = (soFar / milestoneTotal) * 100;\n \n // if the milestone is long past, no need to show it\n if (percentage < 110) { \n widget.addSpacer(6);\n \n // a stack will let us put the name and percentage side by side\n const stack = widget.addStack();\n stack.spacing = 4;\n \n // milestone name\n const milestoneNameText = stack.addText(milestone.name);\n milestoneNameText.textColor = primaryTextColor;\n milestoneNameText.font = Font.boldSystemFont(16);\n milestoneNameText.lineLimit = 2;\n \n // milestone percentage\n const percentageFixed = percentage.toFixed(2);\n const percentageText = stack.addText(`${percentageFixed}%`);\n percentageText.textColor = primaryTextColor;\n percentageText.font = Font.regularRoundedSystemFont(16);\n \n widget.addSpacer(6);\n \n // milestone progress bar\n const milestoneProgressBar = widget.addImage(createProgressBar(milestoneTotal, soFar, 10, false)); \n milestoneProgressBar.imageSize = new Size(width, 10);\n \n milestonesDisplayed += 1;\n }\n}\nLet’s see how that looks:
\n![\"A](\"https://zmknox.com/resources/donation-widget/widget-full.jpg\")
Looking good! I think that’s much nicer than our older large widget.
\nYou can download this script to use on your own device from my GitHub repository. You’ll need Scriptable to run it. I hope you enjoy it. Let me know if you have any suggestions for further improvements.
\nAs I said at the start, this project was hevilly inspired by Matt VanOrmer’s FeedbackBot command in the Relay FM Members Discord and Pyto widget. Additionally, I based some of my code (especially the progress bar) on Juniorchen2012’s widget from the Scriptable gallery.
\n", "date_published": "2021-08-21T17:00:00Z" } , { "id": "https://zmknox.com/2021/05/thoughts-on-xdr/", "url": "https://zmknox.com/2021/05/thoughts-on-xdr/", "title": "Thoughts on XDR", "content_html": "I recently upgraded my iPad from the 2018 11" iPad Pro to the new 2021 iPad Pro 12.9"[1]. I was interested in the speeds of the M1 chip, but what really got me to upgrade (and to go up in display size) was the new Liquid Retina XDR display. This 12.9" display, with a resolution of 2732x2048@2x, has over 10,000 mini-LEDs to serve as a backlight laid out into 2,596 local dimming zones. That sounds fantastic! But what does it look like in practice?
\n\nThe best case scenerio for a display is for the blacks to be truly black and whites to be very bright. an OLED display excels at the former, though sometimes fails to get bright enough (especially uniformly)[2], and an LED-backlit LCD can generally excel at the latter. The mini-LED backlight on this iPad Pro does almost everything it can to do both.
\nHere’s a picture of the iPad Pro in a dark room, displaying an entirely black PNG[3].
\n![\"A](\"https://zmknox.com/resources/ipad-xdr/black.jpeg\")
Do you see it? No? Exactly. The iPad will turn off backlight zones entirely to reach these true black levels. If I pressed the side button to sleep the iPad, it would look exactly the same. For all intents and purposes, it appears that the iPad is not awake.
\nIf you’re in a more well-lit room, you can still tell the bezel apart from the display, as the black treatment they put on the glass has a deeper black point than the display when off. That’s true of basically every display bezel though. Nothing to be concerned about.
\nIn actual use, you can very quickly notice that the black point is far lower than prior iPad models. Gone is most of that LCD muddiness when using dark mode. It’s just black. I’m writing this right now in Kodex with a black background, and it looks fantastic.
\nBut it isn’t perfect.
\nBecause this display only has 2,596 zones to light 5,595,136 pixels, you’re inevitably going to come up against times when the backlight cannot perfectly reproduce what the display may want it to. This results in a bloom effect around objects in a scene. If you look at r/iPad, you may think that this bloom is awful and a dealbreaker for this display, but I don’t think that’s the case at all. So here’s the deal:
\nHere are some examples[5] of the good and the bad. Note that the images I show are not entirely accurate to what you would see in real life, but were taken to give you a visual sense of the what I’m trying to explain. The images were taken on an iPhone 12 Pro with Smart HDR enabled, and were converted from HEIF to JPEG for display on the web.
\nMonsters, Inc. begins with a fun animatic to set the mood for the film, and to convince kids that this movie won’t be as scary as they might think. This opening looks incredible on the new iPad Pro’s display. The blacks are truly black and the motion is quick enough that any bloom that you may notice is almost immediately gone.
\n![\"Monsters,](\"https://zmknox.com/resources/ipad-xdr/monsters-inc.jpeg\")
This movie shows two problems. First: it seems like the black point for this mastering isn’t quite true zero, and that it was matted into a 16:9 frame. This results in blooming around the 16:9 frame, even if there isn’t any content there. I don’t think this is a huge deal unless you’re in a pretty dark room, but is definitely noticable.
\n![\"Star](\"https://zmknox.com/resources/ipad-xdr/the-force-awakens.jpeg\")
Second, this film shows significant display issues when a scene has very moody lighting. This film begins with Poe speaking with an older man. That sequence looks very bad on this display. It’s extremely muddied, making it feel almost like a dream sequence. It’s probably the biggest stress test for this display, and I think the display fails. It looks bad.
\n![\"Star](\"https://zmknox.com/resources/ipad-xdr/the-force-awakens-2.jpeg\")
![\"Star](\"https://zmknox.com/resources/ipad-xdr/the-force-awakens-3.jpeg\")
![\"Star](\"https://zmknox.com/resources/ipad-xdr/the-force-awakens-4.jpeg\")
Parts of this film do look really good in HDR, though.
\nThis video was designed to showcase an OLED display, but I think it does a pretty good job at showing the benefits of this display too. You can see some bloom, especially in the opening shot, but a lot of it feels completely natural, as the objects are big and bright.
\n![\"LG](\"https://zmknox.com/resources/ipad-xdr/lg-oled-demo.jpeg\")
I was curious to try a nature focused show. This one is focused on using special night vision camera tech to see life in the dark. I think the blooming seen here doesn’t detract from the experience at all. It feels similar to how accent lighting behind a TV can look cool.
\n![\"Earth](\"https://zmknox.com/resources/ipad-xdr/earth-at-night.jpeg\")
![\"Earth](\"https://zmknox.com/resources/ipad-xdr/earth-at-night-2.jpeg\")
When watching a Late Night clip, I noticed that the local dimming definitely had a gradient fall off beyond the 16:9 viewing window. I don’t think it detracted from the viewing experience, but I think its worth showing as an example of what the blooming can show as in daily use.
\n![\"Late](\"https://zmknox.com/resources/ipad-xdr/late-night.jpeg\")
The Settings app provides a good example of how the backlight reacts to standard UI in dark mode. There is some bloom in the corners and at the top for the text on a true black background, and a bit of bloom around each of the table view groups, but it isn’t a big issue.
\n![\"Settings](\"https://zmknox.com/resources/ipad-xdr/settings-app.jpeg\")
The bottom scrubber bar of the YouTube app is a bit of an extreme example for blooming. The backlight exceeds the bar for quite a ways. In practice, this feels more like a design choice of the YouTUbe app than a real issue, but it’s definitely noticable.
\n![\"YouTube](\"https://zmknox.com/resources/ipad-xdr/youtube-scrubber.jpeg\")
This one’s a little weird. This webpage allows a device to, for the text in the center, display at a very high brightness beyond its typical white point. It works on my 2018 iPad Pro, and truly shines on my iPhone 12 Pro. Oddly, it doesn’t seem to work at all on this new iPad Pro[6].
\n![\"Wanna](\"https://zmknox.com/resources/ipad-xdr/whiter-white.jpeg\")
I think, overall, this display is very good. In most cases, it will surely improve the viewing experience of anything you’re watching or creating. But it has some clear limitations. Backlight blooming definitely exists, and should definitely be considered if you’re trying to use this iPad as a creation tool. But in daily use, in typical room lighting, I don’t think you’ll notice it very often at all.
\nNow if only they made this screen in an 11-inch size…
\nTechnically the “iPad Pro 12.9-inch (5th generation)”. ↩︎
\nThe latest iPhones 12 do an exceptional job at this for OLED displays. If you’re willing to watch a movie on a display that small, its a fantastic experience. ↩︎
\nFederico also did this in his excellent review on MacStories, but I think it’s worth showing again to really drive this point home. If you want to see this for yourself, you can download the image I made and try it yourself ↩︎
\nYou can see this by looking at a bright object in front of a black background on an OLED display, which has no blooming. ↩︎
\nMost of my examples come from Disney+, Apple TV+, and YouTube, as those are services that I subscribe to which offer 4K HDR content. I’m wishing for the day that HBO Max starts universally supporting 4K HDR… ↩︎
\nOddly, you can see it when blurred behind Control Center ↩︎
\nThe past month has been quite a ride. My app blew up on Reddit, was reported on by big tech blogs, and then was removed by Apple.
\nI’m now happy to report that Stadium is officially back in the App Store! Introducing Stadium 1.2.
\n\nI had to remove my hooks between the GameController framework and WebKit. Apple said that I was “Using public APIs in a manner not prescribed by Apple”. This is unfortunate, but not a complete loss because…
\nI also added a new “Override Custom User Agent” field, which will update the reported user agent after page load, which allows page JavaScript to read a different User Agent string from what you sent in your HTTP request.
\nFinally, I (think I) fixed the tip jar.
\nSet your Primary URL field to
\n![download the image I made and try it yourself](\"https://zmknox.com/resources/ipad-xdr/black-sample.png\"){kind=link}
![blurred behind Control Center](\"https://zmknox.com/resources/ipad-xdr/whiter-white-control-center.jpeg\"){kind=link}
https://stadia.google.com/home\nSet your Custom User Agent String to
\nMozilla/5.0 (Macintosh; Intel Mac OS X 10_15_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36\nSet your Override Custom User Agent String to
\nMozilla/5.0 (iPhone; CPU iPhone OS 14_0 like Mac OS X) AppleWebKit/605.1.15\nDisable “Require Full Screen Video” if you want to see Stadia’s menu overlays. I kept this as an option because forcing the video full screen may be better for smaller devices (hello there, iPhone 12 mini users).
\nBefore you can properly use Stadia, you’ll need to authenticate to Google. In the “…” menu, select “Authenticate Without Custom User Agent”, and when prompted, visit
\nhttps://accounts.google.com/\nOnce you’ve logged in and are at your account page, tap “Done”. You should be good to go!
\nThe Stadia controller will almost assuredly work, presuming that your device is on the same WiFi network as your controller.
\nBluetooth controllers might work. Using the “Override User Agent” I mentioned, Stadia should properly support the Gamepad API, but iOS doesn’t always seem to pass that through. Please send me your feedback on how this works for you! I have gotten it to work more than once, but definitely not every time I tried.
\nKeyboards might also work, but I don’t expect it to be a great experience.
\nThank you to everyone who has been supportive of this project. I’ve received many kind words on Reddit, Discord, and from many in the press. This was a fun little project I built in a weekend on a whim, and I’m glad you all liked it.
\n", "date_published": "2020-11-06T17:00:00Z" } , { "id": "https://zmknox.com/2020/09/stadium-full-screen-browser/", "url": "https://zmknox.com/2020/09/stadium-full-screen-browser/", "title": "Stadium Full Screen Browser", "content_html": "Today, I launched a new web browser app for iOS. It displays webpages in full screen, allows you to change your user agent, has a way to authenticate without the user agent, and has game controller support. How strange!
\nStadium is specialized, but it happens to be great for using game streaming services! I posted a guide on how to use it with Google Stadia on the /r/Stadia subreddit.
\nStadium is free, so I encourage you to try it out with your favorite webpages! (or just want a browser that opens to zombo.com every time).
\n", "date_published": "2020-09-28T17:00:00Z" } , { "id": "https://zmknox.com/2020/08/what-if-developer-id-came-to-ios/", "url": "https://zmknox.com/2020/08/what-if-developer-id-came-to-ios/", "title": "What If Developer ID Came To iOS?", "content_html": "I have an iPhone. I prefer to use it, and its operating system, over other smartphones, but that means I am limited in how I can install apps onto it. Lately, with all of the news surrounding issues in the App Store, I started to wonder: What would the iPhone and iPad look like if they allowed me to install apps from outside the App Store?
\nLet’s imagine it…
\n\n![\"Steve](\"https://zmknox.com/resources/developer-id/sweet-solution.png\")
Today, Apple offers multiple ways to distribute apps for the iPhone, but most of these are fairly specialized:
\nFrom looking at these options, their message is clear: If you’re broadly distributing an app, you need to use the App Store.
\nThe Mac, notably, has an additional option. Developers can use “Developer ID” to sign and notarize[2] their apps to distribute however they want. Apple then allows users the choice of if they want to allow these apps (defaulting to yes)[3].
\n![\"Security](\"https://zmknox.com/resources/developer-id/macos-developer-id-preferences.png\")
This seems to have worked out pretty well for the Mac. Let’s try bringing that concept to the iPhone.
\nLet’s imagine I’m tasked with adding support for Developer ID to iOS. What decisions would I make? What restrictions should I put in place? How will this all work?
\nHere’s what I’d do:
\nTo broadly distribute an app outside the App Store, developers must still sign it and have it notarized by Apple. This is an automated vetting process which gives Apple the ability check for malicious apps, disabling them if necessary.
\nUnsigned apps would not be allowed, in the name of security.
\nDevelopers would be limited in what entitlements they can use. This includes CarPlay, which even today developers must apply specially for, but may also include other limitations such as for HealthKit, HomeKit, or Sign In with Apple. These limitations will likely start somewhat restrictive, loosening over time.
\nApps would still be able to use iCloud and Apple’s Push Notification service, much like Mac apps can today.
\nBefore a user can install one of these apps, they must opt-in via Settings. This would look very similar to the Mac (though with a more “secure” default):
\n![\"Concept](\"https://zmknox.com/resources/developer-id/developer-id-settings-concept.png\")
As an extra precaution, the user must enter their passcode before changing this setting, ensuring that they are the ones who want to make this change.
\nDeveloper ID-signed Apps can be installed via a special kind of link in Safari. This is actually possible today for Enterprise, Ad-Hoc, and Development apps. Developers provide a itms-services:// link to their app manifest, and the system parses it, offering to install the app:
![\"Installing](\"https://zmknox.com/resources/developer-id/ad-hoc-install.png\")
If we’re opening this up more broadly, however, we should expand on this functionality. Turn that simple pop up into a modal sheet including some more detailed text and possibly even some developer information to show who is distributing it.
\n![\"Concept](\"https://zmknox.com/resources/developer-id/developer-id-install-concept.png\")
I would also force any call to open an install link to first bring Safari to the foreground. This makes sure that if you press “Cancel”, you’re in a known trusted app[4]. Apps providing third-party stores or options to update would still be able to link to install manifests, but you would need to go through Safari first.
\nDevelopers must provide their own payment systems, their own validation checks, and their own update check mechanisms. They would not be able to use Apple’s In-App Purchase system, the App Store’s automatic updates, or StoreKit’s receipt validation.
\nThere would likely be a market for third parties to build replacements for these, like how the Sparkle framework can automatically check for Mac app updates on launch.
\nApps in the App Store would not be allowed to promote apps outside the App Store. This includes links in your UI, advertising, and in webpages you link to directly[5]. This rule is in a similar vein to Apple’s rejection of apps linking out to websites for in-app purchase. Once using an App Store app, any digital purchases made within it are using the App Store.
\nApple’s XProtect anti-malware system, used on the Mac, will be put into place on iOS. Any app which Apple flags as malicious may be disabled remotely. In the past, this has almost always been used for intentionally malicious software[6].
\nWith Developer ID support, software distribution would become far closer to how it is on the Mac, where Apple only enforces its review guidelines within its App Store. This will allow for lots of new opportunities:
\nAdditionally, this will provide at least some level of competitive pressure on the App Store to innovate. Developers could still choose to use the App Store for all of its convenience, built-in support for features like In-App Purchase, and trust from users, but it would no longer be the only choice, which may cause Apple to update their rules and rates to compete.
\nThe biggest consequence: malware will probably exist. Will it be common? I don’t know. But it will probably exist, and that’s something Apple has done an admirable job at keeping out of the App Store up to now. I believe that most of the warnings and opt-in requirements in my concept will mitigate a lot of user negligence, but it definitely won’t stop it all.
\nFrom Apple’s perspective, the biggest consequence is losing control. Since the launch of the App Store, Apple has had final say on what can and what can’t be mass distributed to iPhone users, and this changes that. That’s a huge change that they would have to come to terms with.
\nThe rising pressure against the App Store might cause them to implement a solution like this, but the Apple of right now seems unwilling to budge on their App Store policies. We’ll just have to wait and see what the future holds…
\nSpecifically, 100 per device type, which you can revoke when you renew your membership to reclaim slots. Interestingly, it counts iPods separately from iPhones, so if you need a new test device, consider an iPod touch? ↩︎
\nNotarization isn’t strictly necessary, but it is now required for new builds of Developer ID-signed apps as of macOS Catalina. ↩︎
\nDevelopers can also choose not to sign their app at all. This requires users use the “open” command on their app before first launch, and is generally discouraged. ↩︎
\nCurrently, install links will show a simple alert controller, which is useful for enterprise app directory apps, but could lead to popup loops by a malicious app. ↩︎
\nUser-generated content (tweets in a Twitter app, for example) would be fine. ↩︎
\nOne incident where Apple shut a legitimate app down was when Zoom installed a local web server to make it easier to join meetings, which ended up being a big security risk. ↩︎
\nAnd yes, create their own store on iOS. Competition is a good thing! (I can’t imagine they’d like the scary looking ⚠️ I put on the install screen though) ↩︎
\nLast Saturday, I woke up, updated some apps on my phone, and opened my email app, Edison Mail. I was greeted by a splash page telling me about a new account sync feature[1], and to choose which email address was my primary account of the two I had in the app. I selected my Gmail address and tapped continue.
\nAfter I got into my inbox and my email reloaded, something was off. I noticed a notification email from Twitch that a streamer that I don’t watch had gone live. Tapping into the email, I noticed both the username and the email address it was directed to weren’t mine. Going back into my inbox, I noticed a lot of emails that weren’t for me. I opened the sidebar, and there it was. In addition to my two email accounts was a Gmail account that wasn’t mine. Something had gone horribly wrong.
\nAt first I thought it was a fluke bug—a very very bad fluke bug, but a fluke nonetheless. I emailed Edison support and promptly revoked access to my accounts to the app. It soon became clear that this was not just a fluke, but an incredibly bad security issue.
\n\nAbout 2 hours after I tweeted about the issue, Edison support woke up on Twitter and started replying to concerns from myself and others that they were looking into the issue. They later explained that the update had gone out late the night prior[2], and would be being pulled.
\nAfter they had time to shut down the bug and analyze the issue, Edison wrote a blog post (and sent an email to users affected) explaining 6,480 users[3] of their iOS app were affected by this issue. They further explained that users of this version would be locked out and to sign into Edison mail again using the newly released bug fix.
\nEdison also briefly explained the nature of the bug. It effectively linked you and another user together into one Edison sync account. You could access their email, and they could access yours. Do note that this is full access, not simply reading, but writing, deleting, forwarding, etc. Everything you would need to impersonate your new pen pal.
\nFinally, Edison’s blog post explains that “No passwords or credentials were exposed or compromised”. While this may be technically true, it doesn’t mean much when the thing another user did gain access to was my email inbox. Everything goes through email! Receipts, notifications, account recovery, correspondence. It’s probably the number one thing I don’t want to be compromised.
\nIn addition to their’s blog post, Edison’s founder, Hetal Pandya, found her way into my Twitter mentions, trying to defend Edison mail from criticism about their past behavior about neglecting user privacy[4]. Seeing as she reached out to me, I sent her a tweet with questions I had previously sent to Edison support[5] (who still has yet to reply to my support requests). In our exchange, she replied multiple times, but didn’t really answer my questions. This seems to be a trend with all of their responses: to give the minimum possible answer, and dodge the hard questions. As a result:
\nEdison publishes a privacy commitment which reads like a joke now. They claim that “Security is paramount” and “We keep mail private”, which simply weren’t true here. They also claim GDPR and CCPA compliance, which also went straight out the window. Nobody should be trusting Edison with their email until and unless they explain their email security architecture and design. I believe they are capable of explaining this, and they’ve gone in depth before about their data collection design and practices. I look forward to reading your technical deep-dive, Edison team.
\nBut while we wait for them, let’s instead analyze what could have been done to stop this bug from happening.
\nI’m a software developer. I know bugs happen. I also know that bugs this big are capable of being caught before they hit production. Let’s look at ways this bug could have been avoided.
\nFirst, lets assume you’re a new engineer at Edison, and are tasked with working on this WIP feature. You aren’t an architect, and you didn’t choose how your databases are structured. What can you do to avoid bugs like this? Testing!
\nI primarily work on building systems which make it easier for developers to do testing, so I’m certainly a little biased, but I truly think testing can be a valuable tool when dealing with complicated systems like this.
\nYou can test from the smallest scale to the largest. Unit tests will check an individual function’s abilities. Integration tests test how those functions work together. Acceptance tests will run those functions against live (usually development or staging) infrastructure to make sure it all still works together. Automated testing tools are all over the place these days, and continuous integration pipelines make it easy to run them on every commit or pull request.
\nFor this bug in particular, I would test with some dummy Edison Mail users in a staging environment, setting them up with the new sync service to verify that it is working correctly. This could be automated to be done before any pull request is merged or app update is released.
\nAdditionally, I would dogfood the sync feature on my own team for some time to make sure we weren’t experiencing any bugs like this. This process is more manual, but could potentially find edge cases an automated test cannot.
\nIf you’re building this infrastructure from scratch, however, the best approach fixing this bug is to make this kind of bug impossible to create in the first place, keeping each user’s data effectively sandboxed from each other.
\nIdeally, you would let a bigger fish handle your credential storage. iOS allows for this with iCloud Keychain, which will handle syncing for you.
\nBut if your app, like Edison’s, is cross platform, you may want to keep these credentials on a server independent of a platform vendor. To do this, the app could store encrypted credentials on the server created using a key on a local device. When a user wants to log in on a new device, they could send a notification to an active device to approve the login, else require them to re-login to their email accounts. This system makes sure that Edison never has your credentials to share[6], and that your account can only be activated on a new device with your consent.
\nIn case it wasn’t clear: I’m furious with Edison Mail over this bug. Nobody should ever be given access to thee wrong email account by mistake. No apology can wash this away from their reputation. They will forever be the email app that strayed user trust. I’m certainly not trusting them with my email anymore, and neither should you.
\nWhy, then, am I so persistent at trying to get answers on what happened from Edison Mail? Because users deserve to know how their data was mis-handled. Users should know what went wrong, and how its being fixed. This isn’t a “sweep it under the rug” moment for Edison, and they need to know that.
\nNow if you’ll excuse me, I’ll be over here looking for a new email app to call home[7].
\nI was familiar with a similar sync feature from Spark, so I didn’t immediately have concerns about this. ↩︎
\nSpecifically “10:50 PM PST”, which is not currently a valid time zone due to Daylight Saving Time. ↩︎
\nEdison has not made it clear whether this means “users” or “email accounts”. I had two accounts loaded into Edison, and both of them have gotten the breach email. ↩︎
\nIn February, Edison had a bit of a privacy scandal regarding how they use user data (specifically around their purchases) to help drive their other business: selling analytics. In my opinion, while these concerns are valid, I was willing to, at the time, trust that the toggles in Edison Mail’s settings to turn off this tracking behavior would do just that. ↩︎
\nIn case anyone involved deletes these tweets in the future, here are some screenshots of these conversations. ↩︎
\nThey would have access to an encrypted version of your credentials, but, so long as they are done with a secure enough encryption algorithm, this is a non-issue unless you’re being pursued by state-sponsored actors. ↩︎
\nI’m still crying over Mailbox’s shutdown. ↩︎
\n![here are some screenshots](\"https://zmknox.com/resources/edison/conversation1.jpg\"){kind=link}
![these conversations](\"https://zmknox.com/resources/edison/conversation2.jpg\"){kind=link}