Steamclock Software

Summer Camp Pack List: A Guide to First-Time App Store Submission

Fri, 10 Jul 2026 10:00:00 -0700

So, you’ve nurtured your app from a glimmer of an idea into a real, living thing. You’ve watched it grow through bug fixes, UI tweaks, and user feedback (you are gathering user feedback, right?). And now… it’s time. Your baby is off to summer camp for the first time. Or rather, the App Store.

Submitting your app can be a lot like packing your kid’s suitcase for their first summer away—exciting, a little scary, and full of forms. Will they remember their table manners? Will they make friends? Will they get rejected for missing a privacy policy?

This post steps through what to do before your submission, how to make a great App Store listing, and some of the most common rejection pitfalls. We’ve also put together this handy checklist as a quick reference. While some of these tips are Apple App Store specific, many apply to Google’s Play Store as well.

Forms, Snacks, and Sunscreen: What your app needs before submission

Before you start packing that sunscreen and ball cap, you’ve got some permission forms to fill out. Likewise, you’ll want to take a step back and make sure your app is ready to launch before proceeding.

App review can confirm your app meets Apple’s requirements, but it won’t tell you if your onboarding makes sense or how your team will know when something’s crashing in production. This is your chance to make sure that good first impression sticks around.

A solid round of user testing

Before you’re ready to send your kid off to camp, you’ll probably want to test the waters with a night or two away. Similarly, before you’re ready to show off your shiny new app to the world, you’ll want to use TestFlight to gather feedback from beta testers.

Testers will help you identify any potential launch day blow-ups before they happen. Try not to provide too much guidance to testers here—let them discover your app organically and pay attention to any confusion or sticking points they come across.

A plan for catching and debugging issues in the wild

While not strictly necessary, you’ll likely want to launch your app with some tooling to keep track of crashes, bugs, and some basic analytics. Crash reports will help you track down and diagnose those tricky to find bugs that will inevitably slip through even the most rigorous QA. Basic analytics show how users move through your app and which features actually get used. Our current favourites are Mixpanel for analytics and Sentry for crash reporting, but it’s worth spending a little time researching a solution that works for you and your budget.

Support for different screen sizes and aspect ratios

You’ll want to make sure your app looks good on devices of all sizes and aspect ratios, so that every user has a pleasant experience. The big things to look out for here are how your app handles safe areas, adaptive layouts (especially with Dynamic Type enabled), and small screens like that pesky iPhone SE.

A good Privacy Policy

While you won’t have to staple a cheque to any permission slips, Apple requires that every app submitted to the App Store has a legally compliant Privacy Policy accessible in the app and on the product page. This can be as simple as a link to a publicly accessible URL hosted on your website somewhere, but without it your app will be rejected. Also, make sure your Privacy Policy is available on both sides of your app’s paywall, if you have one. This is a common mistake and it’s something Apple specifically looks for.

Dress for Success: How to craft an App Store page that stands out

First impressions are everything, and just like how you want your kid to step off that bus on the first day of summer camp looking their best, you’ll want your App Store page to reflect just how awesome your app is.

Once your app is ready for launch, it’s time to get your App Store materials in order. This is the part where missing small details can turn into real delays, as you’ll likely need to collect input from all corners of your organization like marketing, design, legal, and engineering.

In addition to making sure you’ve got a snazzy app icon and a memorable subtitle, some attention grabbing screenshots are your chance to really shine. Great screenshots will not only explain to users what your app does, but what makes it unique. Your App Store listing should clearly demonstrate your app’s “core loop”—the three or four steps that add up to the most important or coolest thing your app does, and why users will want it. People typically don’t get excited about apps they don’t understand.

Waiting for that first phone call home: What to expect once you’ve submitted your app

You signed the permission slips, you’ve packed the suitcase, you’ve done everything you can to set your kid up for success, and now it’s up to them. Once you’ve dropped your kid off at camp, there’s not much else to do but wait.

App review usually takes 24–48 hours, and we recommend you set your app to manual release so you’re in control of when it goes live—no surprises while you’re asleep or away from your laptop. There’s always a chance you missed something and get the dreaded rejection email, but don’t worry: a rejection isn’t the end of the world. You can always fix your mistake and resubmit your app for review. Unlike your kid getting sent home from camp, you’re always welcome back for another try.

But keep in mind that rejections and re-submissions can take up a bunch of time, so be sure to submit well in advance of any launch milestones you’re planning around. It’s all too easy to slide into a back and forth with Apple because they think your app is a News app, but it’s not a News app, and clarifying that over email takes a week and now you’ve missed your launch date. True story.

Here are some common pitfalls to look out for before you submit your app to save yourself a little time:

Crashes or instability will result in an immediate rejection, and reviewers test on real devices. While the simulator can be great for testing on a wide range of devices, be sure to try your app on as many real devices as you can to simulate an experience as close to your users’ as possible.
Make sure your Review Information section in App Store Connect is updated and accurate. If your app requires a login, make sure to set up a dummy user for the tester. If they can’t log in and test out your app, you’ll be rejected.
Webviews can be a great way to provide dynamic content or temporarily fill in screens that aren’t quite ready for a fully native experience, but they still need to feel native. As a rule of thumb, if a reviewer is able to browse around the wider web inside your webview, you’re likely to get rejected. Make sure your webviews are self-contained, and don’t link out to other pages when possible.
Account deletion should be clear and simple. If you offer users the opportunity to create and sign in with an account, you’ll also need to provide them with a clear and easy way to delete their account and the associated data right in the app. Want to learn more? We’ve got you covered.
Don’t collect any more user data than you have to, and be completely transparent about what you are collecting. You’re also responsible for any third-party services you use, so be sure you understand what information any analytics or bug tracking tools might be collecting.

Your Camper’s All Ready

Submitting your app for the first time might feel like letting go, but you’ve done the hard part. You’ve built something special and now it’s time to share it. With a solid App Store page, working builds, and some monitoring in place, your app is ready to thrive at camp.

Remember that rejections happen, updates are inevitable, and uncomfortable feedback will come. That’s part of the journey. So pack well, check your App Store submission checklist twice, then hit submit with confidence. Your app’s got this.

Building Taste in the AI Era

Thu, 02 Apr 2026 10:00:00 -0700

If your LinkedIn feed looks anything like mine, you’re seeing a lot of posts these days about how “execution is no longer the bottleneck”, as if the difference between an app that works and one that people love was ever about velocity. The “new” bottleneck? Taste. In other words: knowing what to ship and what to leave out, how polished the experience needs to feel, and why. It’s the stuff you can’t delegate effectively to coding agents.

This opens up some questions. Why is taste a bottleneck? What does taste actually mean in mobile product work? Isn’t taste something you either have or you don’t?

Opinions are the experience

Every mobile app is shaped by a product team’s opinions about how it should work. Not Boring’s !Camera app and Halide are great examples. Both apps have die-hard customers, and both reject the default iPhone camera experience. Halide has sharp opinions about how a pro tool should work, whereas Not Boring’s !Camera is opinionated about the joy of photography — it has a bulky 3D UI, fun haptics, and it’s dead simple for point-and-shoot use. These are two apps that essentially do the same thing, but offer vastly different experiences that are shaped by strong opinions.

Opinions matter a lot in mobile development particularly because the constraints are so unforgiving: the user’s attention is scarce, screen space is limited, and the bar for polish is high. To make things even more challenging, when product decisions aren’t backed by clear opinions, the user absorbs a cost. They’re forced to make more assumptions and decisions, and that often leads to hesitation, friction, and churn. A product can be technically functional but still frustrating to use because the opinions behind it are muddled. For example, mobile apps from many major banks tend to dedicate a lot of their experience to seldom-used services rather than focussing on what most people want to accomplish every time they open the app.

All apps are opinionated, some more effectively than others. So how do you know if the opinions behind your product are good?

Taste informs opinions

Taste is a capacity for discernment. It’s an ability to distinguish what’s excellent from what’s mediocre, and to understand why. In mobile apps, it’s what tells you when a transition feels right, when an interaction carries the right weight, or when a recovery state is reassuring enough. Taste is easy to feel but hard to capture in issue tickets.

AI is good at generating plausible composites of existing patterns, which is useful, but that’s not the same thing as product judgment. Considering mobile’s platform constraints, teams need hard-won judgment about polish, custom interactions, performance, and what matters to users in their first session. AI output might look like opinions rooted in conviction, but without expert guidance, those outputs don’t add up to a compelling point of view. So when you combine humans with genuine taste and the efficiency gains of AI-assisted development, you get teams with an even sharper edge than they had before.

But what if you don’t think you have taste? Even more troubling: what if you think you have taste but you actually don’t? Thankfully, taste isn’t a binary either/or. It’s something you can learn and keep getting better at.

Taste is a learnable skill

Most people tend to think of taste as an ineffable je ne sais quoi, but that undersells how trainable it is. A more useful way to think about taste is as a pattern library staffed by an insightful librarian. Like any library, it gets more interesting when you’re deliberate about what you add to it. And a great librarian knows exactly where all the best stuff is kept.

For mobile product teams, building that library means getting better at three things:

1. Study excellent work until you can articulate the decisions. Structured analysis of great work is one of the best ways to develop effective taste. Take an app you love and work through each key interaction until you can identify the specific decisions the team behind it likely made and whether you’d have made the same call. Don’t just admire great apps (or dunk on bad ones). Interrogate their interaction design, pacing, onboarding, notification strategy, and how they convert free users to people who are enthusiastic to pay. Bonus points for making this a group activity: our “Steamclock book club”, where we take a close look at selected Apple Design Award winners, has been informative and a lot of fun.

2. Build a shared vocabulary within your team. A shared vocabulary is how taste becomes organizational. Teams that can articulate what terms like “heavy”, “light”, “fiddly”, and “delightful” mean for a given interaction can hold those opinions consistently across a product and through every stage of the work, from design and development, to testing, and even onboarding. Taste without shared understanding turns into a junk drawer of preferences.

3. Ground the analysis in observed behaviour. Good taste isn’t the same thing as insisting on your own preferences. Take a critical look at your own work, and use key analytics to pressure-test your judgement versus what users are actually doing. Taste gets sharper when it’s informed by behaviour.

The takeaway is to treat taste as a deliberate team practice. It’s also not a hiring problem: if you bring in one person with excellent taste and put them on a team with no shared vocabulary for it, that person’s judgment will get averaged out in no time.

The uncomfortable thing

In practice, teams often feel problems before they can name them. An app ships and it functions, but activation stalls, reviews mention rough edges, or the product simply doesn’t feel coherent enough to earn trust.

This is often a taste problem, but it doesn’t mean the team is doomed. It does mean taste is now a bottleneck, and it needs to be developed on purpose.

New Year, New Website

Tue, 17 Mar 2026 10:00:00 -0700

We have a confession to make: we’ve been so busy helping our clients build great mobile apps that we let our website fall behind.

Our old site had been doing a great job, but it was starting to show its age. More importantly, it didn’t reflect where Steamclock is today or where we’re headed. A website built for “2018 us” wasn’t quite cutting it because our work has gotten more complex — larger projects, more product strategy, more long-term partnerships — and the site wasn’t telling that story well enough.

So, we gave it a refresh.

Make it more… Steamclock

Before we touched fonts, colours, or layouts, we thought carefully about what the new site needed to do — change for the sake of change is rarely a good idea. The old site had a great foundation in terms of navigation and structure, but the details and overall presentation needed to level up. We came up with three principles to guide us:

Show, don’t just tell. It’s easy to say you care. It’s more meaningful to show you care by shipping thoughtful products. We wanted every detail of our new site to speak for itself.
Be human. The tech industry has leaned into clinical minimalism for a while now, with generic sans-serifs, lots of white space, but not a lot of character. We believe apps should feel fun and warm, and our website should, too.
Focus on the work. Fifteen-plus-years of focusing exclusively on mobile apps has given us a level of depth that’s hard to come by. We wanted to apply that same product know-how to our site to showcase the kinds of work we take on and how we solve our clients’ most meaningful challenges.

Steamclock's finest hits are now more front and centre.

Digital love

With these principles in place, we got to work on the finer details. Here are some highlights we’re particularly excited about:

A typographic overhaul. We wanted something that felt both modern and uniquely us, so we landed on Dotties Vanilla, designed by Kyle Letendre for Lost-Type Co-op. It’s a humanist sans-serif with a distinctive friendliness, particularly in italics, which have the specific warmth we were looking for.
It wouldn’t be a Steamclock website without at least some delightful details ✨ sprinkled in, like the app dock footer and phone-shaped contact form. Poke around and you’ll spot a few Easter eggs alluding to our love of mobile.
Dark mode. Finally.

Our site now follows your device's preferred system setting, be it Light, Dark, or Auto.

Hello, World

Websites are often a first impression. Ours now reflects something we believe in deeply: we’re here to do great work, and we sweat the details — not just for our clients, but for ourselves, too.

We hope you like the redesign. If it makes you want to reach out, we’d love to talk.

Special shout-out to Steamclock alum Brady Valentino for helping us ship the refresh!

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