Categories
Technology

State of the Apps 2019

Inspired by CGP Grey’s post that started a Cortex tradition, here’s the current state of my phone:

This is… a work in progress. I got this phone in September, and while it’s been on my mind to do a full reorganization, I haven’t had time to do a full “tear it all down and start from scratch” process. The top two rows, especially, are very temporary — for the first time since iOS 7 came out, I’ve disabled Reduce Motion, and the parallax makes the fake invisible icons trick look terrible.
So rather than go through things in top-to-bottom, right-to-left order, I’m just going to talk about them in whatever order strikes my fancy.

  • Things remains my task management app of choice. I love it across all platforms, and happily recommend it to anyone who’s looking for something more robust than Reminders or a list in Notes. For me, it strikes the right balance of features without getting too heavy, and while I’ve got one or two things I’d like to see added, I have no great complaints.1
  • FoodNoms has been a very nice addition – it replaced Calory, which had replaced MyFitnessPal, which had replaced Lose It!. I’ve got a long history of tracking food, and while I quite liked Calory, FoodNoms is the first time I’ve gone “ah, never mind, don’t need this” and tossed out my notes on how I would build a food-tracking app. I haven’t yet gone for the subscription, because it just doesn’t have any features that interest me, but based on the rate of development, I’m expecting to make that change within the next few months.’
  • Timery is another stellar addition. It’s in that same category as FoodNoms — I had some sketches started of how I’d make an app in this category, and Timery made them completely irrelevant. The last two updates have added some truly excellent Shortcuts integrations — the last one added conversational shortcuts, so I can now just say “Hey Siri, Toggl” and talk through starting a timer with a specific project and description, or kick off a few frequently-used ones with a short phrase. The newest updated added some more programmatic stuff, and I’m planning to take some time over Christmas weekend to rebuild my old Toggl shortcuts, based on Federico Viticci’s examples, with Timery instead of custom web API calls.
  • Toolbox Pro – speaking of Shortcuts, Toolbox Pro is a neat little collection of Shortcuts actions. I’m most excited about the Variables feature, which I’m hoping I can use to improve some of my daily automation stuff.
  • Mail has replaced Airmail. I’d been vaguely looking for a replacement for Airmail, because it had a nasty habit of crashing all the time, and then they did a terrible job of switching to a new business model, and I threw my hands up in the air and decided to try the system default. It’s been working perfectly on iOS; on macOS, I’ve got a cobbled-together system using BetterTouchTool that sorta gives it real keyboard shortcuts,2 and a launchd script that relaunches it when it crashes.3
  • Day One remains my stalwart for journaling, but I’ve been slowly increasing the things I use it for. It’s my archive of Instagram, where I store my sketches, and the app I used to record some interviews I did for class.4
  • Ulysses is where I’m writing this article! It’s still my go-to for any long-form writing, and I love it. I haven’t yet made much use of their recent ability to store Ulysses files in Dropbox (or other arbitrary locations on disk), but I do have a collection of plain-old-markdown files that I edit in Ulysses on my Mac and Sublime Text on Windows.5
  • Reeder is a continuation and an addition all at once — I’ve been using it on my Mac for a while, but didn’t have it on iOS. I hit the maximum number of feeds on the free level of Feedly, and was extremely unimpressed with their paid offerings; I considered making a second account to keep syncing, but decided that was sorta rude to them, and instead opted to not have sync at all. That worked for a while, and then I got a Synology, and after setting it up as a Plex server, spent some time looking into RSS server options. At the moment, I’m using TT-RSS with a plugin for Fever support, but if anyone knows of something that’s easy to set up and has Google Reader API support, I’d appreciate it.6
  • Dark Sky’s recent redesign has me pretty happy. If they let me reorder the types of information, I’d be happier, but the clarity of the “when is it going to rain” charts is still excellent.
  • Overcast remains my podcast app of choice. Podcasts have been a great way to help me establish a gym habit — I established a podcast habit, and then decided that podcasts are things I can only listen to while driving, cleaning, or working out. (If you want podcast recommendations: Cortex, Do By Friday, ATP, 99PI, and MBMBAM are my mainstays.)
  • Strong, speaking of a gym habit, is the driving force of my time at the gym. A couple of my friends have been helping me out with designing actual workout programs to do, but Strong is where I put those in. It’s easy to use, remembers all the numbers so I don’t have to, and has instructions, often accompanied by images or GIFs, on a lot of exercises.
  • Streaks is where I track all my habits, from “did you remember to take your meds” to “do some writing for your blog” to “have you gone to the gym enough times this week?” It’s very good at what it does, and I’m still a fan.
  • Fluidics is a bit self-serving to include here, but I use it all the time. I’m planning to update it eventually — I’d like proper Dark Mode support, at the very least — but it’s hard to find the time.
  • Wallet has gotten more and more important over time, though not as fast as I’d like it to. Let me put my driver’s license in there, already. Apple Card is slowly taking over as my main credit card, Apple Cash is even more handy with the cash back in there, and it’s not too hard to make your own pass of your gym membership.
  • Sleep Cycle is possibly on it’s way out; I’m strongly considering getting a beddit, although I need to do more research — does it have the ‘smart alarm’ feature? How accurate is it? Is Apple going to kill the app soon? Lots of questions.
  • Dark Noise is a new addition in the past few days; I’ve been switching from a ‘sleep’ playlist to white noise in an effort to get Apple Music’s recommendations to not be entirely useless.7 I tried to use Sleep Cycle’s white noise feature for a while, but it assumes that I want the white noise to stop after a while, which is absolutely not the case. Dark Noise’s actual noise is a bit less interesting overall, which is possibly the point, and the app itself is delightfully well-made.

  1. I was, admittedly, tempted by OmniFocus, because OmniFocus for Web means I could have a single unified system across my Mac, iOS devices, and work PC, but it’s still just too much for my needs. And expensive. 
  2. Listen, Apple: you can either comp me the cost of getting a new keyboard that’s got the Inverted T arrangement for the arrow keys, or you can let me go from message to message using j/k. (And even if they did give me a free keyboard, I’d still complain; I’ve been using j/k to get around for two decades now, and it’s just easier.) 
  3. And on Windows, both Outlook and Windows Mail crash frequently, too; apparently IMAP, despite being 30-something-years-old, is still an unsolved problem? 
  4. In typing this, I’ve just realized that I think I’m using Day One the way Evernote wants to be used. Huh. 
  5. All synced by Git, because… why not? 
  6. The Fever API neglected any form of subscription management, and needing to pull up the TT-RSS frontend in a web browser whenever I want to add or remove a subscription just feels silly. 
  7. Fun fact: the “use listening history” setting that all Apple Music clients have? Doesn’t appear to do anything. Neither does “stop recommending music like this.” 
Categories
Programming

SwiftUI’s Picker

I’m very excited about SwiftUI, and have been using what little free time I have to do some tinkering with it. I started during the beta period, which was fun in between being very frustrating; a lovely side effect was that some of the knowledge I picked up is… entirely wrong. One that caught me was the implementation details for the Picker type.
Based on the rather rough state of the SwiftUI documentation for Picker and ForEach,1 I’d assumed that combining the right binding with a .tag(_:) on the items would work:

Form {
    Picker(selection: $selectedItemID, label: Text("Choose Something") {
        ForEach(items){
            Text($0.label).tag($0.value)
        }
    }
    Text("You've selected item \(selectedItemID)!")
}

For reference, the models I’m referring to throughout are pretty simple:

struct CustomModel {
    let value: Int
    let label: String
}

Now this looks like it’s working in simple cases. However, I was trying to interact with a web API, so that items array looked something like this:

var items: CustomModel[] = [
    CustomModel(value: 7, label: "First"),
    CustomModel(value: 3, label: "Second"),
    CustomModel(value: 1, label: "Third")
]

If you tapped “Second” in the picker that SwiftUI generated, however, the text wouldn’t read “You’ve selected item 3!” like it should; it would be “You’ve selected item 1!”
A bit more tinkering revealed that, instead of pulling the value from the .tag(_:) on there, it was just using… the index in the ForEach.2
After some frustrated Googling, utterly despairing of Apple’s documentation, and a lot of StackOverflow searches, I finally figured out the solution:

Form {
    Picker(selection: $selectedItemID, label: Text("Choose Something") {
        ForEach(items, id: \.value){
            Text($0.label).tag($0.value)
        }
    }
    Text("You've selected item \(selectedItemID)!")
}

Quite frankly, I don’t have a good explanation of what’s going on here; last time I was tinkering with Pickers, the .tag(_:) provided SwiftUI with the information it needed to do the binding. (When I’ve got more time, I’d like to do another test — now that I’ve got the id keypath, do I even need the tag?)
I’d love a good explanation of what all the id keypath gets used for, and where else it might be necessary, but alas:


  1. It’s a bit unfair for me to link to No Overview Available when referring to SwiftUI; the coverage is low, but the problem isn’t so much that as the fact that ‘documentation coverage’ just doesn’t work as a metric for something like SwiftUI. The tutorials are a start, and a good sign that Apple was at least trying to rethink their approach to documentation, but they’re not nearly complete enough. 
  2. Zero-based index, of course, which seemed obvious to me, but got me a “???” response when I was complaining about this issue to a non-programmer friend. 
Categories
Programming Technology

Wrapping UserDefaults

UserDefaults, formerly NSUserDefaults, is a pretty handy thing. Simply put, it’s a lightweight way of storing a little bit of data — things on the order of user preferences, though it’s not recommended to throw anything big in there. Think “settings screen,” not “the image cache” or “the database.” It’s all based up on the Defaults system built into macOS and iOS,1 and it’s a delightfully efficient thing, from the docs:

UserDefaults caches the information to avoid having to open the user’s defaults database each time you need a default value. When you set a default value, it’s changed synchronously within your process, and asynchronously to persistent storage and other processes.

How handy is that! All the work of writing to disk, abstracted away just like that. Neat!
Now for the downside: it’s got a very limited range of types it accepts.2 Admittedly, one of these is NSData, but it can be a bit annoying to do all that archiving and unarchiving all the time.
One solution I use is writing a wrapper on UserDefaults. Swift’s computed properties are a very neat way to do it, and any code you write elsewhere in your project will feel neater for it.
The basic idea is this:


There you go: you’ve got an easy accessor for your stored setting.
Of course, we can make this a lot neater; we’ll start by wrapping it up in a class, and make a couple tweaks while we do that:

First, we made a variable to point at UserDefaults.standard instead of doing it directly. This isn’t strictly necessary, but it makes things a lot easier to change if you want to switch to a custom UserDefaults suite later.3
Secondly, we pulled the string literal out and put in a variable instead. Again, this is more about code maintainability than anything else, but that’s certainly a good thing to be working for. Personally, I tend to wrap all my keys up in a single struct, so my code looks more like this:

That’s a matter of personal taste, though.
You might also have noticed that I made both the keys and the UserDefaults.standard private — I’ve set myself a policy that any access of UserDefaults that I do should be via this Settings class, and I make it a rule that I’m not allowed to type UserDefaults anywhere else in the app. As an extension of that policy, anything I want to do through UserDefaults should have a wrapper in my Settings class, and so private it is: any time I need a new setting, I write the wrapper.
There are a few more implementation details you can choose, though; in the example above, I made the accessors static, so you can grab them with Settings.storedSetting. That’s a pretty nice and easy way to do it, but there’s a case to be made for requiring Settings to be initialized: that’s a great place to put in proper default values.4

In that case, accessing settings could be Settings().storedSetting, or

You could also give yourself a Settings singleton, if you like:

I don’t have a strong feeling either way; singletons can be quite useful, depending on context. Go with whichever works best for your project.
And finally, the nicest thing about writing this wrapper: you can save yourself a great deal of repeated code.

Or, if you don’t want to have a default return, make it optional, it’s not much of a change:

You can also do similar things with constructing custom classes from multiple stored values, or whatever else you need; mix and match to fit your project.
(Thoughts? Leave a comment!)


  1. If you’ve ever run defaults write from the Terminal, that’s what we’re talking about. 
  2. If it matters, it’s also not synced; the defaults database gets backed up via iCloud, but if you want syncing, Apple recommends you take a look at NSUbiquitousKeyValueStore
  3. If you want your preferences shared between your app and its widget(s), or between multiple apps, you need to create a custom suite; each app has its own sandboxed set of defaults, which is what UserDefaults.standard connects to. 
  4. UserDefaults provides default values, depending on types, but they may not be the same defaults that you want. If you want a stored NSNumber to default to something other than 0, you’ll need to do that initial setup somewhere. 
Categories
Technology

iOS Notification Routing

The other day I was thinking about the way iOS handles notifications; the new Do Not Disturb stuff in iOS 12 is a good start, but it’s still rather lacking. It’s a fun thought exercise: say you’re Jony Ive or whoever, and you’re setting out to redesign the way that notifications work, from a user standpoint.1 How do you make something that offers advanced users more power… but doesn’t confuse the heck out of the majority of your user base?
After a while dancing around the problem, I came to the conclusion that you don’t.23
Instead, imagine something more along the lines of Safari Content Blockers. By default, the existing system stays in place, but create an API that developers can use to implement notification routing, and allow users to download and install those applications as they so desire.4
Obviously, this would have some serious privacy implications — an app that can see all your notifications? But hey, we’re Jony Ive, and Apple has absolute control over the App Store. New policy: Notification routing apps can’t touch the network.5 And, to prevent any conflict of interest stuff, let’s just say that the routing apps aren’t allowed to post notifications at all.
Alright, we’ve hand-waved our way past deciding to do this, so let’s take a look at how to do it, shall we?
Let’s start with the way notifications currently work. From UNNotificationContent we can grab the properties of a notification:


For proper routing, we’ll probably want to know the app sending the notification, so let’s add the Bundle ID in there, and we’ll also give ourself a way to see if it’s a remote notification or local.

Alright, seems nice enough.6
Next up, what options do we want to have available?
1. Should the notification make a sound?7
2. Should the notification vibrate the phone?
3. Should the notification pop up an alert, banner, or not at all?
4. If the user has an Apple Watch, should the notification go to the Watch, or just the phone?
5. Should the notifications show up on the lock screen, or just notification center?
6. Finally, a new addition, borrowing a bit from Android: which group of notifications should the notification go into?8

Alright, that should be enough to work with, let’s write some code.


Not a complex object, really, and still communicating a lot of information. I decided to make the ‘group’ aspect an optional string — define your own groupings as you’d like, and the system would put notifications together when the string matches; the string itself could be the notification heading.9
And with that designed, the actual routing could just be handled by a single function that an application provides:

And with that, I’d be free to make my horrifying spaghetti-graph system for routing notifications, and the rest of the world could make actually sensible systems for it.
Thoughts? There’s a comment box below, I’d love feedback.


  1. I haven’t done much work with the UserNotification framework, so I’m not going to be commenting on that at all. 
  2. I spent a while mentally sketching out a graph-based system, somewhere between Shortcuts and the pseudo-cable-routing stuff out of Max/MSP, but realized pretty quickly that that’d be incredibly confusing to anyone other than me, and would also look very out of place in the Settings app. 
  3. As a side concept, imagine that but implemented in ARKit. “Now where did I put the input from Messages? Oh, shoot, it’s in the other room.” 
  4. Unlike Safari Content Blockers, though, I think this system would work best as a “select one” system, instead of “as many as you like, they work together!” thing. Mostly because the logistics of multiple routing engines put you back in the original mess of trying to design data-flow diagrams, and users don’t want to do that. Usually. 
  5. I’d call this less of an ‘App Store’ policy and more of a specific entitlement type; if you use the ‘NotificationRouting’ entitlement in your app, any attempt to access the network immediately kills the application. 
  6. Of course, those last two additions wouldn’t be things that you’d be able to set while building a UNNotificationContent object yourself, so perhaps we should be writing this as our own class; UNUserNotification perhaps? 
  7. We’ll assume that setting notification sounds is handled somewhere else in the system, not by our new routing setup. 
  8. This would be at a higher level than iOS 12’s new grouped notifications (the stacks), more like the notification channels in Android: categories like ‘Work’, ‘Family’, ‘Health’, and so on. 
  9. Since we’re Jony Ive, and everything has to be beautiful, we’re presumably running it through some sort of text normalization filter so people don’t have stuff going under the heading “WOrk” 
Categories
App Portfolio Technology

Fluidics 1.1: The Animation Update

The first major update to Fluidics is now available on the App Store!1 In all honesty, it was largely a ‘bug fixes and performance improvements’ update, but I’ve always hated when app updates list that, so I made sure to include a couple user-facing features so there’d be something fun to talk about, at least.
In this case, those features were animations. The most notable is the background – rather than being drawn once, the ‘water’ in the background is now animated, which I think makes the visual effect much nicer overall. Swiping between the three main pages of the app is also much smoother now; instead of a single ‘swipe’ animation being triggered by any swipe, it directly responds to your swipe, so you can change your mind about which direction to swipe halfway through, and it feels more like you’re moving things around, rather than switching pages.2
The big changes, though, are largely invisible; a whole lot of work on the internals to allow for future features I’m planning.3 The gist of it is that a lot of the internals of the app are now a separate library, which means I can share code between the widget and the main app without needing to copy-and-paste all the changes I make in one place to the other.
Past that, there were a couple little tweaks — the algorithm that calculates the water goal is a bit less aggressive with the way it handles workout time, and there’s now a little “this isn’t a doctor” disclaimer in the Settings page that I put there because the lawyer I don’t have advised that I do that.
And, the bit that turned into more of a project than I thought: VoiceOver support. VoiceOver, for those that don’t know, is one of the core accessibility features of iOS; when enabled, it basically reads the contents of the screen to the user, making it possible for visually-impaired people to use iOS. By default, any app built on UIKit has some support for VoiceOver, but the further you go from the default controls, the more broken that’ll get. The way Fluidics works, it was super broken; technically useable, but downright painful to do. After a day or two of vigorous swearing and arguing with the Accessibility framework, I’m proud to say that Fluidics is now VoiceOver-compatible.
If you’ve already got Fluidics on your phone, it’s a free update from the App Store.4 If not, the whole app is a free download from the App Store, and I’m hoping that you’ll enjoy using it. Leave a review or whatever; I’m trying not to be pushy about that.
Oh, and I’m in the process of updating the app’s website; I got such a good URL for it that I want it to look good to match.


  1. There was a bugfix update earlier, version 1.0.1, but that’s not at all exciting, so I didn’t bother writing anything about it. 
  2. If you’re curious, this involved rebuilding the entire interface, from three separate pages that’re transitioned between to a single page that’s embedded in a scroll view. 
  3. And no, I won’t be telling anybody what those are just yet; I don’t want to promise anything before I know for sure it’ll be possible. 
  4. In fact, it may have already been automatically updated — the easiest way to tell is to open the app and see if the water is moving or not. 
Categories
App Music

Variations on the Theme of Life

Grey Patterson

Download on the iOS App Store
I have always been fascinated by the emergent properties of mathematics: simple rules create complex structures. When you get down to it, this is how all of our modern technology works. Variations is based on that concept and was composed for performance through an application written for the iOS® operating system.
At the core of the application are cellular automata based on Conway’s Game of Life (1970), which is a grid where each square is either ‘on’ or ‘off’ and follows a strict set of rules. A square that is off (‘dead’) can become alive (be ‘born’) if it has the right number of living neighbors. A square that is alive can die if it has too few (loneliness) or too many (starvation) living neighbors. The rules are simple, yet they can create astonishingly complex patterns; there is an entire field of mathematics devoted to studying these patterns, Automata Theory.
Variations allows these patterns to play out both visually and aurally. Tap the screen to allow the grid to move through another cycle of living and dying, or just listen to the music created by a single frozen moment. No two people will ever hear the same set of sounds: the starting point for the patterns, as well as their evolution, are uniquely generated every time the Variations application is run.

(The recording above is from the premiere, in which the audience was asked to open the application simultaneously.)

Categories
App Portfolio Technology

Fluidics

I made an app! I’m quite excited about it; this is, after all, the sort of thing I want to spend my career doing.

The app is called Fluidics, and it’s for tracking the amount of water you drink. As I mentioned a while back, I like to do a lot of tracking of what I’m eating and how much I’m drinking. That first part wasn’t too hard; there’s a variety of apps on the App Store for logging food, and after a while I was able to find one that wasn’t too bad.1 For water, though, nothing quite worked – Workflow came closest, but using it to do the sort of goal calculations I wanted was on the line between clunky and painful, and it’s such a general-purpose app that it felt visually lacking.
Eventually I remembered that I’m a computer science major, and why am I sitting around complaining about the dearth of options when I’ve basically got a degree in making the dang thing. Months of sketching, programming, swearing, and repeating the whole thing eventually lead to this: what I hope is the easiest water-tracking app on the App Store to use.
It’s been a fascinating process. (Here, by the way, is where I’m going to take advantage of the fact that this is my blog for rambling and start talking about what it was like making it; if you’d like to get more information on the app, I’ve put together a rudimentary website, or you can skip straight to the ‘it’s free on the App Store’ part and give it a whirl.) As it turns out, there’s a whole lot of work involved in making an app; my original sketch was the widget and two screens. Those came together pretty quickly, but I realized that probably nobody would feel comfortable using an app if the first time they opened it it just threw up a message saying “trust me!” and then asked for a bunch of health information, so I wrote up a privacy policy and started building an onboarding flow. Which then ballooned in complexity; looking at the design files, more than half of the app is screens for dealing with something having gone wrong.2
One of the most interesting debates I had with myself during the whole process was deciding what business model to use.3 The App Store has had an unfortunate tendency to be a race to the bottom; while there’s a bit of a market for pro apps, a minimalistic water-tracking app doesn’t fit into that category. There’s also no argument to be made for a subscription, so I’d narrowed it down to ‘free, because I’m turning it in as the capstone project for my computer science major’, ‘free with ads’, or ‘paid up-front’. The first one was the one I was most comfortable with; sure, ‘paid up-front’ would be nice, but I’d also get approximately zero people to download it what with all the free competitors out there. ‘Free with ads’ feels deeply gross, both because I hate online advertising in general, and because I’m doing a lot with health data, and I really don’t want to have any chance of that getting stolen. For a while, I thought it was going to be ‘free forever’, and I’d be justifying it as ‘building a portfolio’.
That wasn’t what I actually settled on, however; instead, I’m going with ‘free with in-app purchase.’ Instead of building in a paywall and locking some features behind it, though, I decided I’d go simpler; the app and all of its features are free. Starting in version 1.1, there’ll be a button in the Settings; a little tip jar.4 I probably won’t make much, but I’ll feel better about it overall, and what’s the harm?
Beyond that debate, most of the challenge of the project as a whole was just building it. I knew going in what I wanted it to look like; what I didn’t know was how to go about doing that. The way the background overlaps the text? That alone took a week of trying different things to get working right.5 A few things I wanted to include in the first version didn’t make it – the widget was originally going to be entirely different, but the way Apple has done the security on health data makes the original design significantly more difficult to do, so I switched it to the current design.6
It was definitely a learning experience, too – I’d done some iOS application design for classes before, but never gone all-in on making something that would be both functional and enjoyable for the end user. If you’re releasing something on the App Store, you can’t just include a note that says “on first run, it’ll ask for a bunch of permissions; just say yes” because nobody will read that. And getting something uploaded to the App Store is itself a whole process – the App Store page doesn’t fill itself out, after all, and copywriting definitely isn’t my strongest suit.7
But it’s done; I’ve made an app and released it to the world. 8 By the time you’re reading this, it should be available on the App Store; as I mentioned, it’s free to download, and I’d love it if you’d give it a try.


  1. That said, I’m also doing some design sketches for my own entry into the field; don’t get your hopes up, I make no promises. 
  2. I’m not talking “my code is full of bugs and something crashed” went wrong, either; it’s all “the user originally gave permission to do something, but then changed their mind and used the Health app to take it away” and other such nonsense. Computers may be finite-state machines, but “eleventy hojillion” is still a finite number. 
  3. I also talked about this a lot with my friend Chase, without whom I would’ve long ago given up on technology and disappeared into the woods to be a Bigfoot impersonator.. 
  4. Yes, I know, I’m just now releasing version 1.0, and I’m already mentioning plans for 1.1. Don’t worry, I’ve got versions 1.2 and 1.3 mapped out, feature-wise, as well, and have some rough ideas for 1.4. 
  5. For a while I thought I was going to have to write code to draw the numbers ‘by hand’; fortunately, I was able to get the drawing to work by taking advantage of layer masks, but good lord are the Interface Builder files a mess as a result. Behind The Scenes, everybody! 
  6. I do still want to get the original design working, probably as an option in the Settings page of the app; a future version is going to add watchOS support, and I believe that a lot of the work I’ll have to do for that will also apply to making the widget work like I intended, so those two will either be the same or subsequent updates. 
  7. Another shoutout to Chase, who wrote the App Store description and turned my pile of 100 disjointed screenshots into the four that’re currently on display. 
  8. Well, “done”; it’s functional and available to the public, but software, as the saying goes, is never finished, only abandoned. I’ve no plans to abandon this project anytime soon; I use it myself several times a day, so I’m pretty invested in keeping it working and making it better. 
Categories
Technology

iOS 9 and Search

So, I’ve been using the iOS 9 beta for a couple weeks now. (I think? Don’t cite me on dates, I don’t keep track of time very well.)

Other than the app switcher, which I have a whole host of problems with, the biggest bit of weirdness is probably the Search from LaunchPad.1

Because the pull-down-to-search thing is still there. It’s got ‘app suggestions from Siri’ when you first open the menu, which… okay, whatever. And the search functionality itself has improved quite a bit.

But.

That menu off to the left side, with all the suggestions? Super helpful! And… it also has a search bar? The icon for that page is even the little magnifying glass that makes everyone think of search. And using the search bar in there produces… the exact same results.

That just seems like a waste of space to me. Maybe swap it out for direct Siri integration, for those times when you don’t want to be That Guy talking into your phone, but still want to make Siri do some gruntwork for you?

Just a thought.


  1. In case you’re going ‘what is that,’ it’s the Computer Nerd name for the home screen with all the apps.