I have been working on iOS apps since 2009; I started with a collaboration with Wil on AudioScrub (née iLift), and eventually went solo in 2014. After twelve years on the App Store, I've decided it's time to go all-in on the web and would like to share what that means and outline the tradeoffs involved.

The spur for this change occurred years ago after the launch of my seventh app sonogrid. Although the project had iterations over several years, it mostly came together in the summer of 2018: I overworked myself for months, with incessant attention to detail, and was eager to present this to people I would meet during my upcoming trip to Colombia (they really love music there, and this app was for music lovers).

The app launched to a good reception online within various iOS music app communities, but to my dismay, most of the Colombians I met in person were not able to access it because Apple devices are prohibitively expensive there. I would offer to demo the app on my phone and let the other person play with it after: repeatedly, they would enjoy the interface and become immersed in a fun creative process, only to become disappointed on learning that it's not on Android. It was hard to resolve the contradiction between producing something I was super proud to share—a kind of magnificent zenith in my iOS trajectory—and realizing that only half the world can use it.

This was a bit deflating, and I wasn't motivated to do double the work just because of platform duopolies. Added to this was the more subtle but long-standing aversion to the 'review process' that native apps go through before appearing on the App Store: I was hesitant to invest further in an environment with little control and leverage over my own future, with a constant fear of 'reviewer rejection' and the rug slipping out from under me at any time. So I took a step back and haven't updated many of my iOS apps since then.

In place, I worked on various web components and put them together to create about a dozen web-based projects. Contrasting the experience between the web and native (i.e. iOS) worlds, I feel more enthusiastic about how the web is evolving. It can still be 'limited' in comparison to native apps, but that gap is gradually closing and most of my ideas already fit within what's currently possible.

Why you should choose Web over Native

Just to review, in case it's not obvious, there are some more commonly understood reasons for choosing the web over native:

• Basically, all current and future devices (mobile, tablet, desktop) and operating systems (iOS, Android, macOS, Windows, Linux) are supported.
• Projects are simpler and more cost-effective to build and deploy, with tools and skills that are easier to acquire.
• A thriving universe with bazillions of communities spanning the entire Internet provides lots of answers to questions, and most knowledge is based on open standards and therefore highly transferable.
• Backward compatibility is a priority, which means your project is likely to continue working despite technology evolving over time.
• You can make changes whenever you like and have them online within seconds or minutes, as opposed to requiring third-party approval for everything, which could take days or weeks.
• The environment makes it more and more empowering for single-person or small team operations to produce things, without requiring the resources of a large company.

The challenges of the web for developers like myself is to help people 'cross the chasm' that exists due to a lack of common patterns for interacting with apps:

• There is no obvious 'App Store', so people are left to search the wider web (amongst articles, videos, cat pictures, and everything else), but maybe there could be one that celebrates the 'instant' nature of this platform, or a subscription bundle like SetApp to help with discovery.
• There is no universal 'buy' button—every project does this their own way, but the Ghost Portal is becoming more and more common, and I'm trying something similar with my Fund Button.
• The idea of an 'install' button isn't ubiquitous, and some web apps may not be mobile-friendly or local-first, but for the rest there are libraries like a2hs.js that help guide people to make accessing web apps a more familiar experience: simply click on an app icon to launch.
• The lack of an integrated payment system means that every project needs to re-build trust and help others be comfortable enough in the environment to support them financially, but Stripe Checkout, PayPal Checkout, and Web Monetization are contributing various solutions that reduce friction from this process. (I would also love to see fiscal hosting become more prevalent so that having a legal entity is not necessary to receive money.)
• Performance has often held back the types of applications that can be built on the web platform, but WebAssembly will eliminate this issue for a whole class of ideas.

There are plenty of people working to create open solutions to these 'missing features'; it seems like a solvable problem with time.

What it’s like making Native Apps

(Feel free to skip this section if you'd rather not hear me complain about Apple.) I'm sharing some negative aspects of my experience making native apps with hesitation, not to be a downer but because there might be people that aren't really familiar with the developer side:

• The paternal review process can be soul-crushing at times: reviewers don't enforce rules consistently; bad app(le)s get approved and grift people out of money or personal information; it's an anxiety-ridden process that can feel unpredictable. You may have a good impression of Apple if you've bought their products: calling them for support usually means speaking to a friendly person who takes responsibility for your issue and tries to resolve it. App Review on the other hand might as well be an outsourced company, incredibly bureaucratic, and often feels like talking to a rock; any sensuality around the Apple brand quickly vanishes under these bright white office lights as you find yourself filling out TPS reports in the developer cubicle all of a sudden.
• Large companies dominate the App Store listings and generally get better treatment. The lucky independent developers are ones who have the ear of someone who works at Apple to support them if there's a dispute and either push their app through App Review or get it featured.
• It's quite a task for an individual or small team to produce an app, create screenshots and videos, localize everything in multiple languages, respond to reviews, and keep on top of technology that changes every year. The prototypical success looks more like a large organization than two guys in a garage.
• It feels like feeding into a device ecosystem of planned obsolescence and overconsumption, where developers and consumers need to keep upgrading—an insatiable appetite for more.
• The certificates and signing from the build process is complex and can bring development to a halt if you don't have the right combination of XCode and macOS (hint: keep buying new Macs).
• The expanding variety of screen sizes forces you to learn responsiveness primitives which are platform-specific and create a complex array of image and video assets at different sizes for distribution.
• The constantly changing environment will break your app and force you to either hurry and accommodate the changes or receive messages from customers asking why it doesn't work anymore.
• You can't simply share your app with a friend or even install it on your own device without paying rent or getting permission through App Review.

There are obviously lots of positives to native platforms as well, but these kinds of things weigh down smaller operations like mine, favouring large companies with resources and time to deal with this ever-growing complexity.

Developing for Web

Despite the web's challenges, there's much that excites me about its future and some of these characteristics are intrinsic to the platform:

• The concept of instant games promotes highly shareable apps via a simple link that requires no install process: show up and start.
• Having multiple payment providers, potentially with the addition of cryptocurrencies means if you wanted to also just invent your own value system, maybe some kind of post-money coupon thing, it's possible to integrate with existing systems…
• User-controlled personal data stores are already being used on the web and will eventually make their way to native apps.
• Edge apps that work completely in the browser are easy to mirror or fork, and virtually free to distribute: imagine having your site/app available everywhere via IPFS
• The culture of perpetual improvement, with less focus on versioning, is normal: people do not need to 'install updates' for each app they use on every change.
• It's just more fun and with a lower barrier to entry, which results in more diverse and dynamic communities who form part of a larger public commons: more sparks, more life, more weird.

My iOS apps have been quietly free for a while. By mid February 2022, they will disappear forever; I'm not completely sure how this works—I understand you can continue to use them, perhaps even re-download them, but only if you already have it. I would like to eventually re-make them for the web (be welcome to join me or keep me alive). In the meantime, enjoy these apps while they last. I'm jumping headfirst into a world bubbling with new possibilities and excited to develop for the largest open pool of people on the planet.

I have been working on iOS apps since 2009; I started with a collaboration with Wil on AudioScrub (née iLift), and eventually went solo in 2014. After twelve years on the App Store, I've decided it's time to go all-in on the web and would like to share what that means and outline the tradeoffs involved.

The spur for this change occurred years ago after the launch of my seventh app sonogrid. Although the project had iterations over several years, it mostly came together in the summer of 2018: I overworked myself for months, with incessant attention to detail, and was eager to present this to people I would meet during my upcoming trip to Colombia (they really love music there, and this app was for music lovers).

The app launched to a good reception online within various iOS music app communities, but to my dismay, most of the Colombians I met in person were not able to access it because Apple devices are prohibitively expensive there. I would offer to demo the app on my phone and let the other person play with it after: repeatedly, they would enjoy the interface and become immersed in a fun creative process, only to become disappointed on learning that it's not on Android. It was hard to resolve the contradiction between producing something I was super proud to share—a kind of magnificent zenith in my iOS trajectory—and realizing that only half the world can use it.

This was a bit deflating, and I wasn't motivated to do double the work just because of platform duopolies. Added to this was the more subtle but long-standing aversion to the 'review process' that native apps go through before appearing on the App Store: I was hesitant to invest further in an environment with little control and leverage over my own future, with a constant fear of 'reviewer rejection' and the rug slipping out from under me at any time. So I took a step back and haven't updated many of my iOS apps since then.

In place, I worked on various web components and put them together to create about a dozen web-based projects. Contrasting the experience between the web and native (i.e. iOS) worlds, I feel more enthusiastic about how the web is evolving. It can still be 'limited' in comparison to native apps, but that gap is gradually closing and most of my ideas already fit within what's currently possible.

Why you should choose Web over Native

Just to review, in case it's not obvious, there are some more commonly understood reasons for choosing the web over native:

• Basically, all current and future devices (mobile, tablet, desktop) and operating systems (iOS, Android, macOS, Windows, Linux) are supported.
• Projects are simpler and more cost-effective to build and deploy, with tools and skills that are easier to acquire.
• A thriving universe with bazillions of communities spanning the entire Internet provides lots of answers to questions, and most knowledge is based on open standards and therefore highly transferable.
• Backward compatibility is a priority, which means your project is likely to continue working despite technology evolving over time.
• You can make changes whenever you like and have them online within seconds or minutes, as opposed to requiring third-party approval for everything, which could take days or weeks.
• The environment makes it more and more empowering for single-person or small team operations to produce things, without requiring the resources of a large company.

The challenges of the web for developers like myself is to help people 'cross the chasm' that exists due to a lack of common patterns for interacting with apps:

• There is no obvious 'App Store', so people are left to search the wider web (amongst articles, videos, cat pictures, and everything else), but maybe there could be one that celebrates the 'instant' nature of this platform, or a subscription bundle like SetApp to help with discovery.
• There is no universal 'buy' button—every project does this their own way, but the Ghost Portal is becoming more and more common, and I'm trying something similar with my Fund Button.
• The idea of an 'install' button isn't ubiquitous, and some web apps may not be mobile-friendly or local-first, but for the rest there are libraries like a2hs.js that help guide people to make accessing web apps a more familiar experience: simply click on an app icon to launch.
• The lack of an integrated payment system means that every project needs to re-build trust and help others be comfortable enough in the environment to support them financially, but Stripe Checkout, PayPal Checkout, and Web Monetization are contributing various solutions that reduce friction from this process. (I would also love to see fiscal hosting become more prevalent so that having a legal entity is not necessary to receive money.)
• Performance has often held back the types of applications that can be built on the web platform, but WebAssembly will eliminate this issue for a whole class of ideas.

There are plenty of people working to create open solutions to these 'missing features'; it seems like a solvable problem with time.

What it’s like making Native Apps

(Feel free to skip this section if you'd rather not hear me complain about Apple.) I'm sharing some negative aspects of my experience making native apps with hesitation, not to be a downer but because there might be people that aren't really familiar with the developer side:

• The paternal review process can be soul-crushing at times: reviewers don't enforce rules consistently; bad app(le)s get approved and grift people out of money or personal information; it's an anxiety-ridden process that can feel unpredictable. You may have a good impression of Apple if you've bought their products: calling them for support usually means speaking to a friendly person who takes responsibility for your issue and tries to resolve it. App Review on the other hand might as well be an outsourced company, incredibly bureaucratic, and often feels like talking to a rock; any sensuality around the Apple brand quickly vanishes under these bright white office lights as you find yourself filling out TPS reports in the developer cubicle all of a sudden.
• Large companies dominate the App Store listings and generally get better treatment. The lucky independent developers are ones who have the ear of someone who works at Apple to support them if there's a dispute and either push their app through App Review or get it featured.
• It's quite a task for an individual or small team to produce an app, create screenshots and videos, localize everything in multiple languages, respond to reviews, and keep on top of technology that changes every year. The prototypical success looks more like a large organization than two guys in a garage.
• It feels like feeding into a device ecosystem of planned obsolescence and overconsumption, where developers and consumers need to keep upgrading—an insatiable appetite for more.
• The certificates and signing from the build process is complex and can bring development to a halt if you don't have the right combination of XCode and macOS (hint: keep buying new Macs).
• The expanding variety of screen sizes forces you to learn responsiveness primitives which are platform-specific and create a complex array of image and video assets at different sizes for distribution.
• The constantly changing environment will break your app and force you to either hurry and accommodate the changes or receive messages from customers asking why it doesn't work anymore.
• You can't simply share your app with a friend or even install it on your own device without paying rent or getting permission through App Review.

There are obviously lots of positives to native platforms as well, but these kinds of things weigh down smaller operations like mine, favouring large companies with resources and time to deal with this ever-growing complexity.

Developing for Web

Despite the web's challenges, there's much that excites me about its future and some of these characteristics are intrinsic to the platform:

• The concept of instant games promotes highly shareable apps via a simple link that requires no install process: show up and start.
• Having multiple payment providers, potentially with the addition of cryptocurrencies means if you wanted to also just invent your own value system, maybe some kind of post-money coupon thing, it's possible to integrate with existing systems…
• User-controlled personal data stores are already being used on the web and will eventually make their way to native apps.
• Edge apps that work completely in the browser are easy to mirror or fork, and virtually free to distribute: imagine having your site/app available everywhere via IPFS
• The culture of perpetual improvement, with less focus on versioning, is normal: people do not need to 'install updates' for each app they use on every change.
• It's just more fun and with a lower barrier to entry, which results in more diverse and dynamic communities who form part of a larger public commons: more sparks, more life, more weird.

My iOS apps have been quietly free for a while. By mid February 2022, they will disappear forever; I'm not completely sure how this works—I understand you can continue to use them, perhaps even re-download them, but only if you already have it. I would like to eventually re-make them for the web (be welcome to join me or keep me alive). In the meantime, enjoy these apps while they last. I'm jumping headfirst into a world bubbling with new possibilities and excited to develop for the largest open pool of people on the planet.

A while ago, after years of being "analytics-free", I decided to try Plausible Analytics and I want to share what led me to start thinking differently.

The original provocation was learning that Photopea, despite financial success as a one-person operation, earns most of its revenue from advertising and only four percent of its revenue from subscriptions or memberships. Considering that I am trying to finance my own sustainability directly via the people using the app, I thought it curious that this income equalled a sort of 'minimum wage' despite being a well-known, high-traffic project. I don't intend or know how to make something as complex and deep as a Photoshop clone, and so I wondered if I would have fewer opportunities than this—perhaps I need to be open to selling ads at some point in the future, if that's what it takes to keep content freely accessible on the web. (On the other hand, I believe it's better to avoid comparing yourself to others and complexity is not synonymous with income, but I'm not sure how to think about all this at the moment).

Another reason is that I had a hard time turning garbage numbers like 'requests' (which include bots and counts multiple files for each pageload) into something that gives me an idea of 'how many people are actually looking at this?'. I believe in talking to the people who use what you make, but I think many (or most?) people don't have time to write in their impressions, and so this will always be smaller by a magnitude you cannot know; there is value in passive feedback and I think most people would prefer this if it's done with purpose.

So far it feels good. I aggregate visitors to various projects into a single picture. It's nice to have more meaningful numbers and to find out about interesting places that link to you, like this Brazilian guy's tech blog. One of my 100 steps to success, still in-progress, is to track your growth over time, and this is another way to do that.

I hesitated all these years because Google Analytics has become a form of surveillance capitalism, and this taints most other approaches to analytics (or at least our perceptions of it). How can this be remedied? Does it help to use open-source technology? Or if the company hosting the technology aligns with your values? Collecting data generally requires trust because one cannot verify beyond the 'privacy policy'—what about being transparent and just showing what one collects?

Similar to Buttondown, which I use to send mailing lists, I dig the spirit behind the project and its team and would like to lend my support. All this feels holistic so far, but I'm open to having my mind changed again. What do you think?

---

Originally posted in Ephemerata #014.

A while ago, after years of being "analytics-free", I decided to try Plausible Analytics and I want to share what led me to start thinking differently.

The original provocation was learning that Photopea, despite financial success as a one-person operation, earns most of its revenue from advertising and only four percent of its revenue from subscriptions or memberships. Considering that I am trying to finance my own sustainability directly via the people using the app, I thought it curious that this income equalled a sort of 'minimum wage' despite being a well-known, high-traffic project. I don't intend or know how to make something as complex and deep as a Photoshop clone, and so I wondered if I would have fewer opportunities than this—perhaps I need to be open to selling ads at some point in the future, if that's what it takes to keep content freely accessible on the web. (On the other hand, I believe it's better to avoid comparing yourself to others and complexity is not synonymous with income, but I'm not sure how to think about all this at the moment).

Another reason is that I had a hard time turning garbage numbers like 'requests' (which include bots and counts multiple files for each pageload) into something that gives me an idea of 'how many people are actually looking at this?'. I believe in talking to the people who use what you make, but I think many (or most?) people don't have time to write in their impressions, and so this will always be smaller by a magnitude you cannot know; there is value in passive feedback and I think most people would prefer this if it's done with purpose.

So far it feels good. I aggregate visitors to various projects into a single picture. It's nice to have more meaningful numbers and to find out about interesting places that link to you, like this Brazilian guy's tech blog. One of my 100 steps to success, still in-progress, is to track your growth over time, and this is another way to do that.

I hesitated all these years because Google Analytics has become a form of surveillance capitalism, and this taints most other approaches to analytics (or at least our perceptions of it). How can this be remedied? Does it help to use open-source technology? Or if the company hosting the technology aligns with your values? Collecting data generally requires trust because one cannot verify beyond the 'privacy policy'—what about being transparent and just showing what one collects?

Similar to Buttondown, which I use to send mailing lists, I dig the spirit behind the project and its team and would like to lend my support. All this feels holistic so far, but I'm open to having my mind changed again. What do you think?

---

Originally posted in Ephemerata #014.

In preparing Tiny concert for a friend, I audio recorded myself playing guitar while singing and listened back to it immediately after. I tried to do this at least once per day and ended up with four or five sessions repeating this process with the same set of songs.

I was surprised by my noticeable progress in just a few days, and that the process felt productive, self-affirming, and contributing to a healthy relationship with music and the instrument—I actually enjoyed the feedback loop. I noted how my own preferences emerge more clearly: I'm definitely modelling my performance off of the recordings from which I learned the repertoire, but hearing myself makes my inclinations more malleable—music starts to feel more like a moldable material rather than something abstract or 'from someone else'. I thought I would feel overly critical, but it actually trained me to accept and even enjoy my own sound. For a few days I also had a nice routine going of breakfast, reading, stretching, recording, listening back—it felt like a thorough wake-up, leaving me ready to experience the day.

I frequently wondered, "Why have I never done this?". I always knew that people do this, and that I could too, but somehow never gave it a try. I've known about this for a while, since studying music professionally and having been around musicians and their culture for a while. Perhaps it's due to dogmas around perfection that made me feel too intimidated to listen to myself: in one context, music being more about execution than improvisation; in another music being professionalized to the point where sounding 'good' takes precedence over emotional expression. I haven't figured out my answer yet, but I find it useful to ask "What stopped me from doing this and what else is it preventing me from experiencing?"

There were obviously various challenges, but I felt uplifted knowing that one grows by learning to deal with situations. One long-time difficulty of mine is to play music at an unfavourable moment (such as in the morning, before my day starts, in sort of chilly temperature). I found myself working through feelings of clammy fingers and lousy tone, using what I have to construct something (the recursive process of using your own resources to validate your own resources), and building ways to deal with what's at hand. Another difficulty is various hesitations and mental disturbances (thinking too much and other things that impede your flow). I found multiple aspects of performance to help hook myself into the music when feeling distracted: pronunciation, enunciation, helping the body embody the music, voice projection, breathing, etc… It was a relief when I reminded myself that it's okay for me to be somewhat shoddy with my guitar playing because in this context the words are more important. I was able to overcome this binary around "now we're playing the song, now we're not" by constructing mini-routines like tuning the guitar before each performance, allowing myself to revise any ambiguities directly or through improvising, not worrying about how the audience perceives it, and generally opening myself up to be more fluid with music and sound.

To me, the ideals of 'gradual incremental progress' (so common in the world of technology) always seemed at odds with the non-linear nature of music, but I now feel like having arrived at some semblance of it that nurtures more than compromises the practice.

I'm excited to try this more in the future, not only as a way to 'rehearse' but as a way to 'compose'. I also see the approach as part of my broader idea about documenting moments:

For most of life it's possible to look back and observe your own progress. This is encouraging at times when you feel less positive about yourself. All it takes is making a note of where you are with words, sounds, or images.

In preparing Tiny concert for a friend, I audio recorded myself playing guitar while singing and listened back to it immediately after. I tried to do this at least once per day and ended up with four or five sessions repeating this process with the same set of songs.

I was surprised by my noticeable progress in just a few days, and that the process felt productive, self-affirming, and contributing to a healthy relationship with music and the instrument—I actually enjoyed the feedback loop. I noted how my own preferences emerge more clearly: I'm definitely modelling my performance off of the recordings from which I learned the repertoire, but hearing myself makes my inclinations more malleable—music starts to feel more like a moldable material rather than something abstract or 'from someone else'. I thought I would feel overly critical, but it actually trained me to accept and even enjoy my own sound. For a few days I also had a nice routine going of breakfast, reading, stretching, recording, listening back—it felt like a thorough wake-up, leaving me ready to experience the day.

I frequently wondered, "Why have I never done this?". I always knew that people do this, and that I could too, but somehow never gave it a try. I've known about this for a while, since studying music professionally and having been around musicians and their culture for a while. Perhaps it's due to dogmas around perfection that made me feel too intimidated to listen to myself: in one context, music being more about execution than improvisation; in another music being professionalized to the point where sounding 'good' takes precedence over emotional expression. I haven't figured out my answer yet, but I find it useful to ask "What stopped me from doing this and what else is it preventing me from experiencing?"

There were obviously various challenges, but I felt uplifted knowing that one grows by learning to deal with situations. One long-time difficulty of mine is to play music at an unfavourable moment (such as in the morning, before my day starts, in sort of chilly temperature). I found myself working through feelings of clammy fingers and lousy tone, using what I have to construct something (the recursive process of using your own resources to validate your own resources), and building ways to deal with what's at hand. Another difficulty is various hesitations and mental disturbances (thinking too much and other things that impede your flow). I found multiple aspects of performance to help hook myself into the music when feeling distracted: pronunciation, enunciation, helping the body embody the music, voice projection, breathing, etc… It was a relief when I reminded myself that it's okay for me to be somewhat shoddy with my guitar playing because in this context the words are more important. I was able to overcome this binary around "now we're playing the song, now we're not" by constructing mini-routines like tuning the guitar before each performance, allowing myself to revise any ambiguities directly or through improvising, not worrying about how the audience perceives it, and generally opening myself up to be more fluid with music and sound.

To me, the ideals of 'gradual incremental progress' (so common in the world of technology) always seemed at odds with the non-linear nature of music, but I now feel like having arrived at some semblance of it that nurtures more than compromises the practice.

I'm excited to try this more in the future, not only as a way to 'rehearse' but as a way to 'compose'. I also see the approach as part of my broader idea about documenting moments:

For most of life it's possible to look back and observe your own progress. This is encouraging at times when you feel less positive about yourself. All it takes is making a note of where you are with words, sounds, or images.