326: Tree-Planting Features

Welcome to Under the Radar, a show about independent iOS app development. I'm Marco Arment. And I'm David Smith. Under the Radar is usually not longer than 30 minutes, so let's get started. So there's an old adage that the best time to plant a tree... is 20 years ago, but the second best time is today. And I guess we're going to talk today about...

tree planting features. I'm not sure if there's this, but maybe that's not a great name. But it was something that I've been recently very strongly reminded of, of how sometimes we... add features to our apps whose primary benefit will come in the future. And we'll come much later and we will look back with regret at having not done them if we don't do them. And specifically, like a very concrete example of this is analytics inside your application to understand how.

widely used particular features are, being able to understand how often this particular event happens, how often does a user do this. And you can go way down the rabbit hole with this, but something that...

I've found incredibly helpful in the iOS 26 redesign that I'm doing is the places where... Past Dave had the wisdom and insight to add some instrumentation to some features to see how people are using them, what configuration options are popular, things like that. Because I'm doing a lot of what I kind of...

like data informed design through this redesign where I don't broadly subscribe to the like A, B test everything. It's all data driven. Just keep, you know, like the, there's no opinion in this. We should just. come up with lots of designs and just let the math design our app. There is a version that you hear about for some companies that seems to be very much the approach they're taking.

Don't really subscribe to that. I want to be the designer of my app. I want to design it in a way that makes sense to me, that I think is good, that sort of checks the boxes that I care about, even if that is not strictly or technically the most... optimal design from some KPI metric or something. That doesn't appeal to me at all. But what does appeal to me is making an app that is useful and engaging and is helpful to my customers. And so I want to build an app that does that.

And several times in this redesign, because the nature of my iOS 26 redesign is that I have had to go through essentially every screen of my application and make adjustments to it, make changes to it. And some of these are minor, but some of them are major. Every time I go through a screen, I definitely have this running process in the back of my mind asking, you know, is this the best version of this? Or is this still just the version that I designed years ago?

Before the app feature had ever been shown to the public, it was entirely based on the fantasy I have of what this ideal user is using the app for. And is that actually true? And several times when I found, you know, I'm going through and there's, you know, say an example in Pedometer++'s iPhone-based workout mode. Or like this, you know, you hit start workout.

And it shows you previously, it had a fair bit of the screen, like maybe the top 20% was dedicated to a chooser for workout type. You know, are you walking, hiking, or running? When I was doing my redesign, I was looking at this and I was like, I wonder if that's actually useful. I wonder how many people actually ever change the workout type. And I go and I look at it and very few do.

And thankfully, I'd instrumented that in terms of a previous version of the app that let me, you know, reports to the server when that event happens. And so I'm like, oh. This is wasteful. I should not be designing an app that has this big prominent feature that 99% of users are just choosing once. Like they're runners, they're walkers, they're hikers. They're using it for whatever their default case is.

And so instead, now I have a much more compact view of that, that doesn't waste that space. And instead, I can dedicate the space to other features that... you know, warrant it more because of their usage. But it was one of these things where if I hadn't instrumented that particular section of the app, I would have no way of knowing. And all I could do is guess and base it on kind of where I was.

And, you know, there have been a number of times where I really wish, you know, past me had had the wisdom and foresight to instrument a feature because I look at some of these options and I'm like, hmm. I think I could do better. I think I could change it. But, you know, like you don't want to change it if it's, you know, super well received and being highly used the way it is now. Or, you know, there's been places where like there's features that I've put in, kind of put out of this, you know.

off to the side because they weren't very popular, but they would be giving equal prominence. But you can't do this if you don't collect the data. And so in some ways, this episode is just a warning to all of us that our future selves

will never really regret us adding extra bits of data collection or instrumentation to our apps because it'll only, you know, at the cost of some... megabytes of storage on a database somewhere, the future you can be greatly improved through this process.

We've talked a little bit in the past about our analytics efforts and things like that. Obviously, there's the big caveat that you have to be really careful with privacy here. I would strongly suggest simple self-hosted things. There's a lot of services out there that will do a lot of this.

for you, but then you have larger privacy risks with other services doing it, and your users might not appreciate that. You might not want that either. I would strongly suggest simple self-hosted things, and it can be really basic. It doesn't have to be

a really advanced system to get useful data. You know, you don't need every feature under the sun probably. So like, you know, my system is just, you know, it's part of my sync process when the app collects local events and they just basically are... key value things. It syncs to the server, and the server adds it to a database that's not connected to that user. It's like all these anonymous IDs, they rotate constantly, so there's no persistent identities going across more than a few few days.

it's and it just puts it all into a database table and like every day it just basically like there's like analytics today and analytics archive those are the two tables and analytics today is like just all the live events and then every day you know every night there's a cron job that runs to basically

consolidate them into like counts and totals and percentages and stick that into analytics archive and then what i'm viewing when i view my analytics is just that archive data so like all the individual stuff is out because who cares it doesn't matter to me all i want to know is what percentage of people you know use

x or you know of all the people who used x what percentage of the value was a b or c and that can be things you know basic things like you know what percentage of people use the watch app That's a huge question, right? Or even specifics, like what percentage of people use different types of audio outputs? Like what percentage of people use the built-in speaker on their phone versus...

Bluetooth versus AirPlay versus CarPlay. That's useful for me to know for a podcast app. That kind of thing. When you plant those seeds, when you plant those features... You might not realize when you are planting them what you will need them for or what value they will add to you later. But chances are – like I've found that when I do that kind of thing, the percentage of time that it proves to be –

pretty useful down the road is pretty high, like much higher than I thought when I first started trying to collect some basic data like that. It can be simple things like, you know, oh, I'm going to see how many people use this feature and... Maybe down the road that might tell you, as it has with me a few times, huh, I should maybe make this feature better.

Like when I learned how many people use the built-in speaker. I'm like, oh, that's way more than I would have guessed. Let me make the built-in speaker playback better with a custom voice boost profile. Or you might learn, oh, this feature that I thought people used a lot.

It turns out like, you know, less than 1% of people ever touch it. And so maybe that's not worth me rewriting it over the course of two months. You know, if I can use that time in a way that would get a bigger impact for more customers. Once you have those seeds planted, you might even discover ideas that your new data is prompting you that you can now do. For instance, when I started doing listening stats.

as part of Overcast's features last year. I started collecting listening stats because people wanted those end-of-year Spotify rap-style top lists of what you listen to. So now I have listening stats of like... total listening hours certain podcasts get. Well, now I can use that to inform my search ranking algorithm or to inform promotional algorithms because now I know not only how many people subscribe to it, not only how many people star episodes in it, which I knew those for a long time now.

But now I know how long people have actually spent listening to it. So I have all these new signals I can use to improve the app. And if I never collected that data of listening sessions to build that other feature, if I never had planted that seed... All of those possibilities, I wouldn't even think about it. I wouldn't even have those possibilities. So a lot of times you can plant these features not knowing necessarily where they will go. And again, there is always a balance of privacy here.

If you do it very consciously with that in mind, you can greatly reduce your risks of having privacy problems. You know, like what data you collect, how you tie it to anything, if anything, you know, how long you retain certain levels of detail of that data. Like my session data for listening sessions.

I only retain detailed versions of that for the past 48 hours. And then that also gets consolidated down into, you know, a consolidation table. And, you know, so there's all sorts of, and that, by the way, that's why my undo feature only goes back 48 hours. That's for that reason.

So, again, planting these seeds, you don't necessarily know where they're going to go. Some of them are more obvious. Some of them are like, hey, how many users do I have? That's worth knowing. But some of them, you might not know where it goes. The other thing is like... Sometimes you have kind of an oh crap moment. I can't tell you how many times during Instapaper and during Overcast that I wished I could like display a message of some kind.

on old versions of the app that, for instance, if long ago I had abandoned iOS 12 compatibility and I was about to cut off the API on the server side that iOS 12 communicated with. I would love people to post a message in the app for users of that old version saying, hey, sorry, this is going to end on this date. And I couldn't do that. Because the only way you can do that is if you build in a system.

that lets you post messages in the app remotely from the server without doing an app update five years ago. Because now you can no longer update that version of the app because you've moved on. So it's like one of those features of like, you know, hey, put in... A feature that you can change something server-side or change a file on S3 or something and display a message in the app without touching the app code. That's another one of those features where like...

I wish I had that for years. I did finally build it when I did the rewrite last summer. I finally put that feature in. I didn't have it before that. And it only took a couple hours maybe to get all that worked out and have the whole web interface on my admin panel to edit the messages and stuff. I have a minimum, maximum build for each message so I can show it to just one build of the app or every build before.

this build or whatever i want to do and you know it took a few hours now i have that in place so now five years from now when i have to deprecate the api that i use for ios 17 clients or whatever i can post a message there i can do that that work is done And you never know when you're going to need that kind of stuff. So if you think something like that might be useful to you at all, even if you think someday maybe I'll use this, if it's not that much effort to build, put it in there sometime.

Take a boring Thursday or whatever and put it in there sometime. Take the day before. I'm going to do some maintenance work. I'm going to build a really boring feature that I might really appreciate that I have five years from now.

Yeah. And I think it's been surprising to me how easy these kinds of things can be. So like my analytics system is even simpler than yours in the sense of all I have is a very simple. It's like what web server that's – has a database behind it. And all it does is aggregate counts. So like the simplest form of analytics that I think you can do that is super helpful still is just purely event-based. So it's just...

When an event happens, it reports that to the server, and in my case, it just adds counts. Like, I don't keep any... personal data whatsoever, everything is immediately aggregated and just reported in sort of these very broad, big buckets. And I don't record, you know, the user's IP address or any, it's not attached to you. I don't even have user identifiers. So that wouldn't even be a thing I could do.

But it's completely sort of anonymous and private in that way. But it's still super helpful. And it was something that – as you said, it was not very difficult to write this because it is the world's simplest website because all it does is – is essentially a wrapper around some SQL queries that are just wrapping it to make sure that it's SQL injection safe and all the right things in terms of it's...

safe in that way from my database, but it's not doing anything. It's just writing to a database. And it's a super simple, straightforward thing. And very often on the other side, for the other kind of features you're describing with, you know, I wish I had an announcement.

thing and it has definitely been added to my list as a result of you describing your announcements feature so thank you for that it's so good but several places in my in my apps I have things that are driven from a very simple, like just a JSON file on a file server somewhere, which is, you know, and very often with these in the Swift world now, I just do this with, you know, I have a configuration struct.

I make it codable and write that codable to a JSON file and that's it. And like, it's super easy. You take that file and put it on a server and you can just reconstitute it using the JSON decoder. And there you go. And I found that to be super straightforward and easy and like... It's, you know, in terms of you have a web front end to update the messages. It's like if I had that system and had a message that I needed to send, I would just be manually editing a JSON file or...

something along those lines and then, you know, uploading it to a file server. And that's in some ways kind of awkward, but also is super scalable and straightforward because serving static JSON files. you can do to millions of people concurrently with not much hardware or effort. I think I do most of mine with R2 and Cloudflare. That works great. It's been absolutely rock solid, very reliable, very dependable. Don't have to deal with scaling issues. And it's something that is so...

It almost feels like it's too easy, that it should be this big, complicated thing. But I can say from my experience, even just having something super basic and straightforward like that will go a long way. And yeah, it's the ability to reach. back into the past is such a a weird thing and i think it's i've definitely learned the you know time and time again it is be as yeah don't try and instrument features in

that you know you need the data for. I mean, in some ways, you should have already been doing that. But try and just instrument as much as you can, as much as is reasonable in your app. Anywhere that you have... I guess in some ways it's trying to understand where inside the user's experience do they make choices. And very often what I want to understand is which choices are people making, at what frequency, at what intervals.

he has worked really well for me. I remember years ago, I used an analytics package that was doing way more advanced stuff with this, where it's like, And it gets a bit more into the privacy challenges where, you know, it would try and instrument users pathing through the application and things, you know, so they do this event and then they do this event and then they do this event. And if it's complicated, like.

flow diagrams and stuff. And I'm sure that's useful in some ways, but honestly, 90% of the time, I think I can get enough information out of just if a user is making a choice, which of the choices are they making at what frequency? And you can infer, I think, a tremendous amount from that information without needing to worry about these super sophisticated, complicated, data-intensive, privacy-concerning things, like just a very simple...

collect event counts system. And on the other side with, you know, just things that are driven in the app based on JSON files, like you can go a tremendous distance with just those two things. We are sponsored this episode by Incogni.

Data brokers are out there in the business of collecting your personal info. And this is a really creepy, gross business. Nobody likes the idea of these companies collecting your personal info and, you know, showing up in search results for your name so anybody can look up, like, you know.

your phone number, your home address, like all this, you know, disgusting stuff. So Incogni, what they do is they reach out to data brokers on your behalf. They request that your data be removed. They send these, you know, the takedown and removal notices to these. And if the data brokers object with any part of it, they deal with it for you. So you don't have to go out there and deal with hundreds of data brokers and new ones as they pop up, filing takedowns and opt-outs and everything.

Incogni specializes in that. So here's what you do. You protect your privacy in three easy steps. You just create an account, grant them the right to contact data breakers on your behalf, and that's it. You just kick back and they get to work.

They will tell you their progress. They have a user-friendly dashboard to provide updates on the status of whatever rule requests they're currently filing. So with Incogni on your side, you can reduce the amount of data brokers getting your contact details along. So you can say goodbye.

to annoying spam and all the creepy risks that come along with this kind of thing. Incognity makes protecting your privacy easy it would take you hundreds of hours to do it manually even just you know maybe even just one data broker and then you would need to repeat that process every few months as new data brokers continue collecting your data and creating new records so incogni will take all this work off

your hands visit incogni.com slash radar and secure your data today sign up and enjoy a 30-day money-back guarantee protect your privacy with incogni and experience peace of mind knowing your personal information Take your personal data back with Incogni. Use code RADAR via the link in the show notes, and you'll get 60% off an annual plan. Check it out now, incogni.com slash radar. Our thanks to Incogni for their support of this show.

show and all of Relay. There are also certain factors too. I think before we quite leave that topic, as you do your levels of how many people make this choice, One thing I have always valued is anytime you have a setting in the app or a view mode to a screen...

instrument that. See how many people actually use that setting. How many people, like, you know, if you have some kind of obscure setting that is, you know, maintenance for you to maintain over time, like, oh, this screen you can view as a list or a grid or, you know, or whatever.

How many people ever switch that? Whatever your default is, do you have like 99% of people who just leave it on the default? Maybe you can get rid of the other option sometime. As you are maintaining it over time, it's useful information to know.

huh, when I'm redesigning the screen, do I want to do two different designs of the screen to accommodate these two different modes if only 1% of people are using the other mode? That kind of thing can be very valuable as you... plan things and evaluate things and you know evaluate cost and maintenance over time yeah because i think it is a funny thing where increasingly in my mind when i'm developing and designing things i have in my mind that like

A feature or a situation needs to be used by a meaningful proportion of users for it to be something that justifies. sort of further attention and time. And I shouldn't be too precious with, well, I built it once, and so I need to maintain it and include it and have it be there forever. And this manifests itself in so many different ways. But I think really, unless it is the differentiation between Obviously, you're...

like premium features are going to be used by much fewer people than your free features. So like that differentiation doesn't quite follow this rule where if you're building your app for the 95% case, obviously your premium situation would be slightly different. than that, but within each of those categories, building things that are focused around how people, the majority of users are actually using the app is so valuable and so helpful. There's so many times this summer

as I've been doing these iOS 26 things and I'm like, I go and I look at the data. I'm like, this feature is used by nobody. And so I don't. I haven't given it much time. And that's been super helpful with the summer that's been so busy and so complicated. And there's been so many things that I need to update.

And like, there are a couple of screens. Like, I think I've gotten to the point, you know, I'm pretty happy with my iOS 26 updates, but there are a few places in, you know, especially in Widgetsmith where it's like, this is, it turns out, this is a feature that hardly anyone ever uses or ever opens.

those creatures and screens just got the, I opened them, I made sure they were not broken, and then I moved on to something else that was actually valuable and useful. But knowing which of those things is the thing that needs, you know, that you can essentially do the light type.

only make sure it's not broken, and then move on, requires that work that I've done in the past few years to collect the data. So I know this particular feature, this particular screen, doesn't need quite the level of polish. That's something else would. And eventually maybe those screens in some way should just disappear out of the app. But that is a difficult and much more complicated thing to do than just trying to understand where your emphasis is.

would your time be best spent? Because you're going down the common path that most users are doing. And so it can just be something that's super helpful to do. And I suppose this is one of those, in the same way that I now have it to do, to add a announcement system to my app if you are not collecting any of these kinds of things. And I think sometimes maybe I've seen some people who have like a badge of honor that they don't collect any data.

as though this is something that they should be proud of and something that they are proud of. And I mean, I'm not saying like if you're proud of that, like – Be proud of what you want to be proud of. But I would say there has been a time in my career and a time in my history where I was much more on that side of things. And I think in some ways the way I view it for myself now is that what I was saying is – I know better than my users, and I don't care how they're using it.

I know better. And that's the harsh version of what I was saying to myself. And I think increasingly I have a much more clear-eyed view of that, that I can learn a lot from my customers. And the way to do that is with...

privacy, you know, preserving analytics. And as long as I do things in a clean, careful, intentional way, I don't need to feel bad about collecting general information about my users in a way that allows me to make the better for them and makes me more efficient in my work because I can truly focus on things that are going to be used and impactful rather than just sort of guessing blindly in the dark or basing it all on myself.

As much as it would be lovely if you're building an app where you are that... The 99% user that does everything in the way that everyone does, that is unlikely to be the case because that's just not the reality of my life. I've tried building those apps in those ways and inevitably I find out people like... core of the app, but they're using it in a way that is slightly different than necessarily the way that I do. I think there's a great philosophical divide there.

Because I actually usually in most ways that I run and develop my app, usually I am more on the side of I'm going to do this the way I want. Or I'm going to do the features I want to do and I hope people like them, but I don't know. That is usually closer to how I operate. But I don't think that is totally at odds with collecting data.

I think you can operate as the app dictator. There's probably a nicer term for this, but you can operate that way if that's how you choose to do your app, which again, that's usually the choice I make. You can also be informed by the data. There are a lot of insights that you would only have by looking at some of this data. And there's, as we mentioned, prioritization, certain kind of...

basically unblindfolding yourself. You don't have to guess as much. Like, is this working? Do people use this? Do people like this? Are they getting this? You don't have to guess as much when you have data behind it. The data can just tell you. And you can still, if you want, like... Just because you have data does not necessarily mean that you have to make every decision by popular vote.

If everyone uses this one thing and not this other thing, you don't have to get rid of the other thing, or you don't have to necessarily not ever change those things. But you can know the decisions you're making. It's like you can know the rules that you're breaking before you break them. Or you can decide, you know what, this thing is really...

but I really like it. So maybe I'll see if I can somehow convince more people to use it. Or maybe I'm not showing the value of it as well as I could or something like that. So you don't have to necessarily... give up creative control of what you're doing with your app by collecting data. It's up to you what you do with the data and how you prioritize the insights that you get. But if you don't have any of that data... You are just guessing, and you're going to guess wrong a lot of the time.

Yeah, and I guess it's better not to guess. And so as we wind down our summer work here and we're thinking about squeezing in these last few features for iOS 26, this is just something we wanted to put out there. If you don't have any of these things, it's probably a good... A reasonable time to do it because it's going to be a lot of upheaval and change, I suspect, in a couple of weeks. I think our next episode of this is coming out on the other side of...

Probably the iOS 26 submissions would have opened. And so it's like it's a wild time in some ways, but it's going to be a very interesting time to just understand how people are using your apps and the best way to. to understand that is to have this thing. And as we get towards that, I guess in some ways it's like my best wishes to all of our listeners who are thinking about submitting iOS 26. apps. I think this summer has in many ways been a

a narrative arc between you and I of the various challenges and travails of the summer and of getting our apps ready for I was 26. And sometimes that has been delightful and sometimes that has been utter despair. And I think.

In the end, we will hopefully be there to some degree like i'm getting close to my uh you know the point where i put up a sign in my office that says no more new features which you know is essentially me saying i'm done like and now i just need to polish and uh make things good and i don't think you're quite there yet from some of the conversations i've you know

were saying on this week's atp but you're definitely seeming in a better place than you were before and so as we wind down the summer um you know i think this is mostly just like thanks everyone for enjoying the journey it's been really fun to hear people who found our our journey helpful in this process because it has been a really interesting summer. Oh yeah. Yeah. Quite. I think an arc is putting it nicely. It's definitely a rollercoaster.

But yeah, it's been a journey. We're not through it yet, but we're almost at the end. I'm in a better place overall. There's still a lot of bumps along the road. I'm still not happy with... you know, kind of what I was able to get done versus not get done this summer. But that's developer life sometime. And that's kind of why, getting back to earlier, why it's valuable to have insights that can help you prioritize things. You can never do everything you want to do. There's never enough time.

I certainly never have enough time. So I have a huge to-do list. I cannot wait to get... ios 26 out of my way so i can get back to writing features i've laid some exciting groundwork for features that i really am looking forward to i i can't wait to get back to working on the features and instead i've been stuck doing this redesign that i hate so

So it's almost done. I'm almost back to the feature part. And I'm looking forward to getting through the next few weeks. Thanks for listening, everybody. And we'll talk to you in two weeks. Bye.