Steamclock Software

The Future of Mobile Computing

Thu, 11 Dec 2025 10:00:00 -0800

As we wind down Steamclock’s 15th year, we have a lot to reflect on. Over the years we’ve worked with our clients to ship apps that have mapped the internet and helped save over 35 million pounds of waste from going to landfills. We’ve supported five of our clients’ apps through acquisitions, and we’ve even partnered with Reddit to train an army of clandestine Cold War operatives.

During that time we’ve seen a lot of change, whether it’s new tech stacks, business models, hardware specs, cloud capabilities, user preferences, or UI conventions. Every aspect of the mobile experience has continued to evolve.

But as much as things have changed, the basic mobile experience in 2025 would be pretty familiar to anyone in 2010 — poking at apps on a screen we hold in our hand. Considering how fast tech seems to be moving in 2025, how will mobile computing change over the next 15 years? Will we even have apps in 2040?

Steamclock’s co-founders, Allen and Nigel, and our Managing Director, Nick, looked at this question from three different angles: software, hardware, and social norms. Here’s what we see ahead.

Allen: The More Things Change…

The early years of mobile development were tumultuous. New APIs, frameworks, and approaches changed how teams worked on a yearly cadence. Over time, of course, the ecosystem settled down – we now understand the use cases well, and the development practices and frameworks are well established (with the possible exception of newcomer Kotlin Multiplatform). The majority of mobile dev is now about iterating and refining existing products.

At least, until recently. LLMs are changing development dramatically, as they make certain tools and techniques easier to implement (for example, refactoring codebases, rapid prototyping, and building with the most popular frameworks) and make others more difficult (for example, models are less adept with custom in-house app frameworks than the tried and true).

Even more profoundly, LLMs have unlocked a whole suite of product experiences that were never before possible. Some of these are experimental – we need to try them to discover the future – but others are just clear wins for UX and functionality. While the early years of LLMs featured a lot of chat interfaces, there are a raft of non-chat AI experiences that are just emerging.

"While the early years of LLMs featured a lot of chat interfaces, there are a raft of non-chat AI experiences that are just emerging."

These new capabilities and techniques will overturn many mobile apps. Some will be outcompeted, others will be reinvented. While much will change, one thing will stay consistent with the last 15 years: teams with a keen focus on using great UX to build strong businesses will find a lot of opportunity on our most personal devices.

Nigel: Looking Back to Look Ahead

The most recent disruptive change in hardware, the shift to smartphones as most people’s primary computer, started with the release of the iPhone in 2007. However, in the 15 years before that, there were plenty of signs that handheld computing devices were likely to be the next big thing.

Newton, Apple’s previous take on a mobile computer, was released in 1993.
Palm Pilot, much closer in form factor and behaviour to a modern smartphone, was released in 1996
Blackberry, the first glimmerings of a mobile device with modern internet connectivity, was released in 1999.

All of them were horribly compromised in various ways. Poor screens, poor connectivity, limited functionality. Only the BlackBerry could reasonably be described as a hit. We can say in hindsight, though, that all of those products had the right idea. And even in 1999, you could do the converse of Steve Jobs’ famous “Are you getting it? These are not three separate devices. This is one device”, and look at a Newton and a Palm Pilot and a BlackBerry and an ordinary cell phone and say “Once these are one device instead of separate ones, a lot of people are gonna want one of them”. Actually making that happen was incredibly hard, but realizing it was probably going to happen was not.

So when we are thinking about any hardware disruption within the next 15 years, there’s a good chance the Newton, Palm Pilot, and BlackBerry of that shift already exist. The strongest candidate for that is AR glasses.

Google Glass, Meta Ray-Bans, and Apple Vision Pro are all horribly compromised devices, functionally limited in some huge ways, with battery problems, weight problems, insufficient display resolution, and prices that vary from “too expensive” to “eye-wateringly expensive”. I could not, in good conscience, recommend that anyone buy any of those right now or invest too much time in developing software for them.

But as with the early mobile devices, you can look at where those devices are now and say two things:

If you can get something that is the size of a normal pair of glasses, doesn’t cost much more than a modern smartphone, and can do what the Vision Pro does, a lot of people are going to want one.
All of the technical advancement required to make that happen in the next decade or so seem totally plausible.

On the hardware front, that’s going to be what I’m keeping an eye on. There’s a good chance that at some point, possibly sooner than we think, AR glasses are going to have their iPhone moment, and when that happens, an exciting new world of mobile software could open up very quickly.

Nick: TMI in 2040

The future of mobile computing will depend a lot on people’s attitudes toward privacy. Increasingly, the more information we share with companies about ourselves, the more personalized and “thoughtful” AI-enabled software can become. While providing that information today comes with tradeoffs that often feel worth it, attitudes may shift as more of our data becomes easier to access, centralize, and act on without our direct intervention.

It’s not hard to imagine a future where, at a networking event, your mobile AI assistant quietly lets you know that you’re talking to Edith, who you last saw in person a year ago. It reminds you that her oldest daughter, Elle, is now studying architecture, that you and your partner have been meaning to have dinner with Edith and her husband, Emil, and that you’re all free on the 24th. Fiorino, Emil’s favourite restaurant, has a table at 7 p.m. The deposit has been paid.

Almost all of this is possible today with current technology. But to do this well and consistently would require something like root access to your life — continuous permission to read and write information about who you meet with, where you go and when, your social media footprint, all your messaging platforms, and your payment details. The more information you and everyone you know provide to a centralized system, the better that system can work, and the harder it becomes to step away from.

"The more information you and everyone you know provide to a centralized system, the better that system can work, and the harder it becomes to step away from."

But how comfortable should we feel giving companies (and the organizations they’re beholden to) root access to our lives in order to make remembering and buying stuff easier? In practice, people trade privacy for convenience all the time. When the payoff feels high enough, the risks feel low, and you know other people who are doing it, online privacy often doesn’t feel like a big concern. Think location sharing for maps and rides, or fitness trackers. So the question is whether the benefits of personalized mobile technologies will keep pace with the increasing amount of visibility and control companies will need to deliver these new services.

Secure on-device models and processing could address some of these concerns. It’s not hard to imagine technology advancing over the next 15 years to the point where on-the-go agentic performance becomes snappy, consistent, and helpful. Today, though, the reality seems pretty far away from that, where vast data centres are required to power “agentic” personal experiences that feel more like limited demos than dependable assistants.

Ultimately, mobile computing in 2040 could be determined less by technical constraints than by human ones: the norms we set, the regulations we pass, and the defaults we’re willing to accept. When building that future, we could treat privacy like a dial, where personalization isn’t just about anticipating our needs, but about letting us set clear, reversible limits on how and when our data is used.

The Only Constant

No one knows exactly what 2040 will look like, but the next 15 years will bring deep changes to both technology and society. What counts as an “app”, the hardware we run them on, and even our shared sense of “normal” technology use are all up for grabs. A lot of products will ship in that time. We’ll be focused on which ones actually stick — and how to help build them.

You Only Live Twice

Fri, 05 Dec 2025 10:00:00 -0800

Three years ago, we (and our sibling company, Royal Pixel Service) put Two Spies — our spy-vs-spy strategy game for iOS — into maintenance mode. By that point, the game had already seen an incredible run: a 4.7-star rating and over one million downloads.

Since then, aspiring secret agents from around the world have continued to play Two Spies, share stories about their matches, and hope that one day the game might get an update or two from HQ.

As it happens, a core group of leaders at Reddit were among those agents. They believed in Two Spies and saw an opportunity to bring it to millions of new players. So earlier this year, Reddit reached out to us about building Two Spies directly into Reddit using their new developer platform.

And that’s exactly what we did.

Two Spies, Made for Reddit

We completely rewrote the game to take advantage of Reddit’s developer tools while keeping the same turn-based deception mechanics players love. We even added new features, like a global leaderboard and user-generated maps, where players can toggle cities on or off to create their own custom challenges.

Each post in the game’s subreddit represents a map, and anyone with a Reddit account can jump into a match. Best of all, Two Spies now works everywhere you use Reddit: Reddit’s mobile apps and on desktop browsers. After years of requests, Android agents can finally begin their espionage training!

You can find the game on Reddit at r/PlaySpies, and we’d love to hear what you think.

We’re incredibly grateful for the love and support the community has shown Two Spies over the years, and we can’t wait to mint a brand-new generation of 00 agents.

Play Two Spies on Reddit

Three Changes in Android 16 That Might Break Your App

Wed, 16 Jul 2025 10:00:00 -0700

Google rolled out a flurry of AI demos, developer announcements, and… AI demos at Google I/O 2025. But looking past Google’s LLMapalooza you’ll find a grab bag of under the radar deprecations in Android 16 (released June 10th) that are bound to cause headaches as users start upgrading.

Three changes in particular deserve attention: changes to edge-to-edge layouts, portrait locking, and back navigation. Whether you’re maintaining a production app or planning a new release, it’s worth staying on top of details like these to keep problems from sneaking up on you over the coming months. Let’s dive in.

1. No More Edge-to-Edge Opt-Out

Starting in Android 16, Google has deprecated the ability to automatically make sure app content doesn’t overlap with an app’s nav or status bar. Android encourages developers to embrace edge-to-edge layouts—designs that extend behind the system status and navigation bars at the top and bottom of the screen—for a more immersive feel. Before Android 16, if you didn’t want to update your app manually to handle edge-to-edge designs, you could simply opt out and have the OS take care of the additional padding for you.

That option is going away in Android 16. Apps now must respect system insets, meaning you’ll need to manually account for padding around navigation bars, gesture areas, and status bars. Otherwise, your content risks being overlapped or hidden altogether. For apps with older layouts or don’t-worry-we’ll-fix-this-later padding hacks, this change could lead to unexpected UI bugs.

2. Portrait Locking is Being Deprecated

The ability to lock an app in portrait mode via the manifest is being phased out. Essentially, Google is forcing devs to support landscape orientations for tablets and foldables now (in Android 16) and phones next year (in Android 17). While there are still a couple of workarounds to force portrait mode programmatically—manually handling an onConfigurationChanged() callback, or requesting Portrait orientation in the Activity—both may have unintended side effects depending on the use case.

For teams that relied on portrait locking as a shortcut to avoid layout complexity, this is a not-so-subtle nudge from Google that adaptable designs aren’t optional anymore.

Predictive Back navigation is the ability to let users preview where a back gesture will take them before they fully commit. It was introduced back in Android 13, and it required effort to make it look and work well. Android 16 is doubling down on Predictive Back navigation by turning it on by default while also deprecating KEYCODE_BACK and removing onBackPressed() altogether, which until 16 was the typical approach for handling backpresses.

The predictive cross-task animation (source: Android developer documentation)

This means apps now need to use the newer OnBackInvokedCallback system or risk broken navigation flows. If your app has custom back handling for web views, forms, or nested navigation, this is a breaking change that you need to test for deliberately.

Next Steps

These changes (and others introduced in Android 16) point to a theme: Google is pushing Android developers toward more adaptable, future-proof designs that support new kinds of interactions and device types.

While that future might sound exciting, the reality is that as Android users upgrade their devices (and as more devices roll out with 16 pre-installed), the work needed to handle these deprecations and keep apps feeling polished and durable can’t be ignored.

New versions of Android typically don’t see super-quick uptake, but planning for these updates now sure beats scrambling to fix things after it’s too late. If you’re navigating the transition to Android 16 or just want a partner that obsesses over this kind of detail, let’s talk!

Solving Android Login Issues with Chrome Custom Tabs

Wed, 14 May 2025 10:00:00 -0700

When Android developers need to display a web page in their apps, most folks tend to opt for WebViews. But I recently came across a situation in a hybrid mobile app that required Chrome Custom Tabs (CCTs) instead, specifically for Android login flows.

The problem? The CCT was sharing session cookies with the Chrome browser, and these cookies weren’t cleared on logout. This meant users were being logged back in unexpectedly—not a great user experience.

While CCTs aren’t new, I hadn’t had a good reason to check them out before facing this particular challenge. So with my curiosity piqued, I jumped in to learn more about what CCTs are, what they’re good for, and how they could help solve this login screen problem.

Enter Stage Left: Chrome Custom Tabs

CCTs are a feature within the Chrome browser on Android that enable customized mobile browsing experiences. They’re available on any Android phone where Google Play Services is installed, and they can be identified by their distinctive toolbar at the top of the screen.

CCT in Dark Mode, API 33.

Some key benefits:

Security: CCTs leverage the installed Chrome browser’s regular updates, ensuring up-to-date security and performance improvements without additional app-level updates. And unlike WebViews, CCTs come with off-the-shelf integration with Chrome Password Manager, meaning things like login autofill works seamlessly and without additional setup or restrictions.
Performance: CCTs have a pre-warming mechanism and share resources with the Chrome browser to speed up webpage performance, so they’re a great fit for “feed-style“ screens (e.g. news, subreddits, chat, etc).
User experience: Unlike WebViews, which are embedded directly in XML layouts or constructed in code, CCTs are launched using an Intent, opening a dedicated, lightweight browser Activity that acts as a host container for the component, powered by Chrome. This approach provides users with a seamless browsing experience, allowing them to navigate smoothly between your app and web content without losing context or feeling disconnected.
Backward compatibility: Because CCTs rely on the Chrome browser’s rendering engine, they’re less susceptible to Android WebView API fragmentation issues.

Solving Problems with CCTs

Turning back to the issue of the logout problem described earlier, a WebView-based solution was disqualified right off the bat since the app needed to display a CCT-based login screen for… reasons™️. With that hard constraint in mind, we looked into other ways of clearing shared session cookies, including CCT custom HTTP Headers and Incognito Mode. But it was a combination of three key adjustments to the Redirect URI that did the trick:

Sometimes, the best way backward is a redirect forward.

Send a new REST API request from the web app to clear session cookies (i.e. GET /sso/saml in the diagram).
Have the Native Android side intercept this new request by adding an <intent-filter> to the Manifest, with scheme, host and optional path set to listen for the new Redirect URI (ie. rzplnecct://logout).
Add logic to open the Login CCT programmatically, and verify the new Redirect URI and associated API call.

In practice, because the session cookies are cleared by the web app, the OAuth Redirect URI isn’t sent as it was before, meaning users aren’t logged back in automatically after logout. Success!

Disclaimers

While CCTs are a great tool in certain circumstances, here are three trade offs to keep in mind when considering them for your projects:

Visual Styling

Like a stubbornly bright accent wall in an otherwise dim and cozy room, CCTs tend to stand out. Fortunately, Google offers a way to mitigate this, at least partially—a set of APIs are available for making some basic CCT style and UI changes, including: toolbar colour, entry/exit animations, a custom close icon, toolbar auto-hiding, and some custom toolbar actions. While not perfect, these APIs can help keep CCTs better aligned with an app’s overall visual design.

CCT with a themed toolbar, API 31.

Closing CCTs Programmatically

There’s no direct or easy way to close a CCT programmatically. The reason for this has more to do with how Activities work in Android than with CCTs themselves. But having said that, to close a CCT, Intent flags need to be added to manage the Android Activity stack:

How to “close the door” when leaving a CCT.

Set android:launchMode="singleTop" in your Activity’s Manifest entry. This ensures the original Activity instance remains.
Launch an intermediate Activity (New Activity) with FLAG_ACTIVITY_NO_HISTORY. This ensures it’s removed from the stack once closed.
When New Activity finishes, start the client Activity with these Intent flags to clear Custom Tab Activity from the stack:
- FLAG_ACTIVITY_CLEAR_TOP — removes any intervening activities above the target
- FLAG_ACTIVITY_SINGLE_TOP — ensures the existing Activity instance is reused
Handle cleanup in the original Activity’s onNewIntent() method.

Custom Headers and Security

One more important quirk to be aware of is how CCTs pass custom HTTP headers. CCTs take a more secure approach than WebViews by checking for a pre-registered Digital Asset Link (a “signature” in the form of a JSON file) that’s used to prove app and domain ownership. This implies that custom HTTP headers can only be used on websites owned by an app’s author. While this boosts security, it can get cumbersome in scenarios like white-label apps.

Final Thoughts

Once I got a handle on their quirks, I was pleasantly surprised by how easily CCTs integrate into complex workflows. Whether you want to verify requester trust, leverage Chrome security features, or embed web content smoothly, CCTs offer valuable advantages alongside traditional WebViews—no need to choose one vs the other since both can happily coexist in the same project.

If you’re considering adding CCTs to your app—or if you’d like a hand getting started—we’d love to help out. Drop us a line!

You Are Here: How Teams Make Product Decisions

Fri, 14 Mar 2025 03:00:00 -0700

In 2007, I was lost. Not existentially, just geographically. I was somewhere in northern Italy, wandering through narrow and unmarked roads. This was still roughly the pre-smartphone era, and my “learn Italian by singing” CDs proved less useful for communicating than for embarrassing myself.

Of course, it is only in retrospect that we know we are lost. At the time, I was iterating toward success. This piazza is definitely that one on the map, which means my hotel is around the next corner. Nope. But that clothesline looks familiar…

Scoping new features for an app is a lot like exploring a new city—roadmaps are great, but without a pinch of humility and a fix on your current location, chances are you’re headed in the wrong direction.

Lost and Found

What does it mean to “know where you are” in product development? One way to define it: understanding why you’re making the decisions you’re making.

→ What mix of gut feel, pressure from Sales, and user feedback went into the team’s decision to add AI-assisted writing tools to our product?

→ Are we going all-in on gamification because our competitor did, or because of something we observed in how people are using (or not using) our app?

At Steamclock, we’ve shipped great mobile apps on iOS and Android for hundreds of clients, and this has given us a lot of data about how a product team’s underlying motivations influence their success. From what we’ve seen, motivations are a strong indicator of whether a team is on the right track, or if they’re headed into a costly 🎶 strada senza uscita 🎶.

Two questions in particular are helpful for zeroing in on where a team is and if they’re heading in a good direction:

Are your decisions builder-driven, or customer-driven?

Are your decisions based on observed behaviour, or desired behaviour?

Plotting these two questions on a chart—with “builder vs. customer-driven” on the x-axis, and “observed vs. desired behaviour” on the y-axis—is a useful way to frame this conversation because it defines four regions that map out where you are versus where you might want to be:

Easy answers typically aren’t the most honest answers, so these questions can be surprisingly uncomfortable and contentious to wrestle with. That’s why they’re valuable. Let’s take a look at some approaches to answering these two questions and the implications of the four regions they define.

Vision vs. Feedback

No product or feature is 100% customer-driven—it takes vision on the part of a builder to make a new thing based on the belief that it should exist. Henry Ford’s famous (but misattributed) quote comes to mind: “If I had asked my customers what they wanted, they would have said a faster horse.” Sure, and on the other hand, Ford’s sales dropped by 75% between 1923 and 1927, fuelled in large part by Henry’s single-minded fixation on a purely builder-driven outcome.

Successful product teams place themselves somewhere between “pulling a Henry” and “building every customer request”, using methods like those described in The Mom Test to gather high-quality feedback. To get a handle on which way your team is leaning on the builder-customer axis and their potential blind spots, you can start answering questions like:

Which of our assumptions have been invalidated by talking to customers?

What do we do when what we want is at odds with what customers are telling us?

What will we do if we don’t get the traction we’re expecting for this new feature?

How often do we release new features without customer validation?

Observations vs. Aspirations

Billion-dollar industries have been built on the gap between our real selves and our over-confident aspirational selves (this is definitely the year I’ll finally learn Italian). Also true: billions of dollars have been wasted creating apps and features in ill-advised attempts to change customers’ well-worn habits. If you don’t believe me, I have a web browser to sell you on a monthly subscription basis.

But knowing this behaviour gap exists and doing something meaningful about it are two very different things. This is a famously hard challenge at the core of user experience design, and solving it depends on the data we gather from real world users.

(For a great discussion about gathering good data from users, I highly recommend checking out this episode of It Shipped that Way featuring Teresa Torres (Product Discovery Coach and author of Continuous Discovery Habits.))

Where are you on the observed-desired axis? The following prompts offer a solid start to pinpointing your location:

How are we validating user feedback with observed real-world behaviour?

What conversations are we having with customers to understand the bedrock motivations that drive their routines and habits?

If customers are requesting a new feature, what workarounds have they put in place until they get it? Have they bothered?

Are we making product decisions based on vocal users, or behaviourally representative users?

In the Neighbourhood

Now that we’ve sketched out what the two axes mean and how we might plot our position on each of them, let’s take a look at the four regions they define. But keep in mind that how “good” a region is depends on your present circumstances, and the goal isn’t necessarily to stay in a single region forever. Just like when you’re exploring a new city, you’ll find that different neighbourhoods have different trade-offs, and some are a better fit for your current needs than others.

Builder-driven, Desired Behaviour

Teams in this region are typically building according to how they think people should act, with very little evidence. This is often where new apps start, but successful teams generally move toward the “observed behaviour” end of the spectrum as soon as possible.
From what we’ve seen on most client projects, the longer a team stays in this region the lower their chances of success. A good approach to get things rolling in a more effective direction: start talking with customers to see which of your core assumptions they can invalidate.

Customer-driven, Desired Behaviour

This is typically a risky place to be since there may or may not be a real need, and customer interviews are only as valuable as the questions that get asked. Instead of asking leading questions like “wouldn’t it be great if…” that tend to confirm our own biases, try bringing the customer back to the moment of a specific past behaviour to unearth a richer recollection of their experience—start with “Tell me about the last time you used Instagram. At lunch? Ok, what did you do next…”. The conversation with Teresa Torres linked to above goes into more details on this.
Of course, opinionated software can sometimes be a good thing. When customer insights aren’t giving you clarity, it can be helpful to pick a direction, gauge the response, then make adjustments based on your new findings.

Builder-driven, Observed Behaviour

This isn’t a terrible place to find yourself—the team is building based on interesting behavioural insights. There’s a vision, and the direction seems to be pointed toward product-market fit.
If teams stop at surface-level observations without digging into why customers behave a certain way, there’s a risk of mis-applying those insights. Make sure you’re exploring deep enough by asking your customers good questions.

Customer-driven, Observed Behaviour

The highest performing teams working at scale are generally found in this region, but there’s a danger of taking things too far—over-indexing on how things are and not enough on how they could be can put your team too far into this corner.
Sometimes, the customer isn’t really asking for a faster horse.

Journeys and Destinations

Making software for people would be easy if it wasn’t for people—we all have evolving biases, aspirations, blind spots, and expectations that muddy the waters. This messy humanness is what makes product management so hard. So to build effectively you need to stop, do some honest introspection, and course-correct every once in a while.

Knowing where you are—whether you’re leaning too heavily on vision, chasing unrealistic customer aspirations, or aligning with actual behaviour—is the difference between getting lost and building something people love.

Steamclock Software

The Future of Mobile Computing

Allen: The More Things Change…

Nigel: Looking Back to Look Ahead

Nick: TMI in 2040

The Only Constant

You Only Live Twice

Two Spies, Made for Reddit

Three Changes in Android 16 That Might Break Your App

1. No More Edge-to-Edge Opt-Out

2. Portrait Locking is Being Deprecated

3. Back Navigation is Changing

Next Steps

Solving Android Login Issues with Chrome Custom Tabs

Enter Stage Left: Chrome Custom Tabs

Solving Problems with CCTs

Disclaimers

Visual Styling

Closing CCTs Programmatically

Custom Headers and Security

Final Thoughts

You Are Here: How Teams Make Product Decisions

Lost and Found

Vision vs. Feedback

Observations vs. Aspirations

In the Neighbourhood

Builder-driven, Desired Behaviour

Customer-driven, Desired Behaviour

Builder-driven, Observed Behaviour

Customer-driven, Observed Behaviour

Journeys and Destinations