The work and times of the app development team at Steamclock.

Archive (41) RSS Feed

Allen Pike • April 5, 2021

Hiring a Senior iOS Developer

Over the years, Steamclock has hired pretty infrequently. Our growth has been slow and steady, and our team members tend to stick around!

In 2021, though, we’ve geared into a higher growth mode. We’ve already hired an excellent Android developer, and have a position open now for a Senior iOS Developer. So if you’re an iOS Developer in British Columbia, we’d love to chat!

If you’re not a senior iOS developer, but you’re really into building great apps, it still might be a good time to say hi. We have big plans, and are going to need more thoughtful, skilled, and empathetic folks to execute them. 🌈

4.5.21.109

Accent Accent

Allen Pike • March 3, 2021

Google Blinks on Tracking

In February, we wrote about Apple’s coming restrictions on SDKs that send data to companies who track users across websites, and the potential App Store rejections that may begin when those rules come into effect. We advised then then that all iOS apps that were using Google Analytics, Google’s Firebase, Flurry, or Facebook SDKs to prepare for potentially migrating off, in case neither Apple nor the trackers backed down.

Luckily for users of Google’s SDKs, it seems Google has blinked, according to the Wall Street Journal:

Google plans to stop selling ads based on individuals’ browsing across multiple websites, a change that could hasten upheaval in the digital advertising industry.

The Alphabet Inc. company said Wednesday that it plans next year to stop using or investing in tracking technologies that uniquely identify web users as they move from site to site across the internet.

Google has published some more details about this move, which doesn’t mention apps or Apple explicitly, but seems focused on disavowing the specific thing Apple has declared war on: tracking individual users across different companies’ services.

Today, we’re making explicit that once third-party cookies are phased out, we will not build alternate identifiers to track individuals as they browse across the web, nor will we use them in our products.

As per that article, it seems like Google’s machine learning algorithms, such as Federated Learning of Cohorts, have evolved to the point where they can get almost as useful ad targeting from ostensibly anonymized data.

In addition, Flurry Analytics, another popular provider of analytics SDKs whose business model historically included selling data to advertisers, has also disavowed per-user tracking, at least when it comes to their iOS SDK:

Flurry will respect Apple’s policy requirement to not combine data across apps and websites owned by other companies.

Facebook’s story is a bit muddier – they’re certainly very publicly opposed to Apple’s moves, but their SDK docs now have reams of information on how to try to comply with the rules, including how to use a new feature they call “Aggregated Event Measurement”, along with fun guidance like this:

If you plan to deliver ads optimized for conversion events that occur on your business’s website, configure 8 preferred web conversion events per domain in Events Manager. Aggregated Event Measurement limits domains to 8 conversion events that can be used for campaign optimization. Facebook will initially configure the conversion events we believe are the most relevant to your business based on your activity. Ad sets optimizing for a conversion event that is no longer available will be paused when Aggregated Event Measurement launches in early 2021. While not usable for optimization, events not configured as one of the 8 conversion events for a domain can still be used for partial reporting in Ads Manager and website Custom Audience targeting.

Got it?

Letter of the law, or spirit of the law?

The upshot is that even Facebook, the company with the most to lose, seems to be moving towards compliance. That said, by the letter of Apple’s guidelines, it’s not yet clear whether Facebook’s half-hearted approach will net its SDK consumers an App Review surprise come iOS 14.5.

Even with Apple’s new “Additional guidance” at the end of their documentation on App Privacy labels, it can still be pretty challenging to determine if you’ve set up one of these SDKs to fully meet Apple’s “does not track you” seal of approval. Currently the App Store asks developers to indicate that an app “tracks you” if it is “sharing data with entities who display third-party ads”. It seems like this would apply to using any SDK owned by Google, regardless of their tracking behaviour. However, Google and Flurry have now both very publicly disavowed tracking users across sites, which seems like it would make their SDKs okay by the iOS 14.5 rules.

Clearly, some clarification from Apple is needed here.

Still though, this progress seems to indicate that the feared SDKpocalypse will probably not occur. While more privacy-conscious and full-featured analytics tools like MixPanel are still a win for a lot of teams, adtech-funded SDKs seem likely to continue on in many iOS apps, now that it’s clear per-user tracking is not a hill that Google wants to die on.

Facebook, however? The jury’s still out.

3.3.21.733

Accent Accent

Allen Pike • February 8, 2021

Is Apple Banning Free Analytics SDKs?

This story has moved a lot since it was published – our update from March 3 tells the latest.

Apple announced last summer that they will soon require users to opt in before apps can get the infamous “IDFA” tracking identifier for that user. While this was controversial in the ad tech sphere, most mobile apps can get by without this identifier.

However, most mobile app teams do collect analytics to help make product decisions. What features inspire free users to convert to paid users? Why do we think our trial is converting poorly? Do we still need to support iOS 12? A lot of apps use free SDKs to collect and analyze this kind of data.

The most popular analytics SDKs are free because they’re owned by companies that sell ads, or share data with those companies: Google Analytics, Flurry, and Google’s Firebase. Paid competitors like Mixpanel and Amplitude can be really powerful, but often cost thousands of dollars a year or more.

Now, I can’t find this said explicitly anywhere. But it seems like, along with the incoming restrictions on IDFA and ad attribution, Apple is also enacting a de-facto ban on these free analytics SDKs. The setup looks like this:

  1. Since December, App Store Connect’s App Privacy submission process has required developers to indicate if they have “3rd Party Tracking”. Developers are told to do this if they’re including an SDK from a company that hosts ads or shares data with advertisers across apps.
  2. In the coming weeks, iOS 14.5 will require apps that engage in “3rd Party Tracking” to ask explicit permission, which most users will opt out of.
  3. App Review will soon start rejecting apps that are not following the opt in provisions. They’ll likely do this by comparing the app’s App Privacy metadata to the use of the new opt-in APIs, as well as scanning apps for the presence of certain SDKs.
  4. Therefore, it seems, iOS apps currently using the Google Analytics, Flurry, and Firebase SDKs may need to migrate off of them promptly and instead use an analytics tool not owned by a company that displays ads. Popular choices include Mixpanel, Amplitude, or a self-managed analytics tool.

These new rules could be a big hurdle for some developers, especially if they currently rely on other SDKs that do 3rd party tracking or attribution, such as Facebook’s.

Do we really have to?

The challenging thing for developers evaluating all this is that many of the points above have not been said so explicitly by Apple. Apple has instead outlined a series of rules, each rule being worded somewhat differently between the App Privacy documentation and the App Tracking Transparency documentation. A generous reading makes it seem like you maybe could comply with the rules and still use some of these SDKs. Maybe.

Apple did not – and from a legal perspective likely can’t – explicitly ban the Google Analytics, Flurry, Facebook, and Firebase SDKs. Their wording leaves some wiggle room. It seems like it could be possible to use them. It seems even more possible that Facebook and Google could make them usable. However, this puts developers in the situation of evaluating the changing documentation, complex privacy policies, and large settings panels that these tools offer, trying to judge whether a given setup of a given SDK would now pass muster from Apple’s perspective.

For example, in App Store Connect – where developers indicate if they have Third Party Tracking – Apple asks if your app is:

Sharing data with entities who display third-party ads.

It seems maybe impossible for a Google-owned analytics SDK to not trigger this provision. In contrast, the AppTrackingTransparency documentation asks whether you are:

Placing a third-party SDK in your app that combines user data from your app with user data from other developers’ apps to target advertising or measure advertising efficiency.

Does it matter if the SDK combines user data in general, or is it sufficient if you’ve been assured that your app’s user data in particular won’t be combined by the SDK? The logical complexities and differences in wording raise questions that, unfortunately, developers need to make assumptions about until we hear something from Apple, or we hear through the grapevine how App Review actually enforces these rules. In particular we need to make three guesses:

  1. Will you be allowed to indicate your app has 3rd Party Tracking, not implement the opt-in dialog, but still get App Review to approve you as long as you believe you’re not required to do opt-in based on your evaluation of the SDK, its settings, and the exact wording in the AppTrackingTransparency documentation? Our guess is no. It seems likely that Apple will expect that all 3rd Party Tracking requires the opt-in dialog.
  2. Will you be allowed to include an SDK that App Review considers a “3rd Party Tracking SDK”, but not indicate 3rd Party Tracking in your App Privacy data as long as you believe you’re not required to based on your evaluation of the SDK, its settings, and the exact wording of the App Privacy documentation? Our guess is no. It seems like Apple will probably consider any use of the Facebook and Google SDKs to be 3rd Party Tracking.
  3. Is it safe to continue using – or migrate to – 3rd party product analytics tools like MixPanel and Amplitude that are not owned by advertising companies? Our guess is yes. These rules seem squarely aimed at companies involved in advertising.

If one of the above assumptions is wrong – for example, maybe these SDKs can be configured to behave sufficiently privately, and App Review can be convinced that this has been done for your app – then that would be really useful to know. If anybody has more information on what Apple will or won’t be allowing, or even conflicting hunches, let me know.

Does our SDK require App Tracking Transparency? Uh… well…

Firebase, Google Analytics, and Facebook have been releasing updates and documentation to help developers navigate Apple’s questions, but conspiciously they don’t directly answer them. Instead they answer different, related questions that are maybe helpful but are certainly not decisive.

Contrast that to paid analytics tools that don’t share data with ad companies. MixPanel, for example, posted clearly 6 months ago that they believe they’re compliant with Apple’s rules:

You need to specify what data is used to track someone across external apps and websites, which in our case is none. We only allow customers to track data they own; data sent to Mixpanel is not used by any other external companies.

Interestingly, Flurry – whose business model apparently is to share data with advertisers – has also claimed its SDK doesn’t trigger the App Tracking Transparency rules. This seems dubious, but is interesting if so.

However, if the above rules and assumptions are correct, any apps that don’t both purge these SDKs and set their App Privacy to say they no longer have 3rd Party Tracking – or only use the SDKs for the small percentage of users who opt in – will soon face rejection. Meanwhile, even besides these restrictions, there are some substantial benefits to using premium analytics services like Mixpanel.

Our advice for now, then, is that all iOS apps should be prepared to migrate off of the Google Analytics, Firebase, Facebook, and Flurry SDKs, potentially on very short notice. If you were already on the fence, now is probably a good time to make the move. A lot of apps might be making changes in the coming weeks.

Hold on to your butts.


Updates, February 11 through March 3

A number of developers have gotten in touch to share their guesses about how App Review will handle this in the coming weeks – thanks folks! Some common themes:

  1. Many developers assume Apple will only be using App Review to enforce opt-in for the IDFA identifier, and will not start rejecting apps for using SDKs that go against their new rules prohibiting things like combining data and using fingerprinting, as long as developers assert their SDKs are following the rules. This is plausible. If Apple goes this route though, developers are left with the ongoing risk of a surprise rejection, when App Review later cracks down on a specific SDK that’s played loose with the rules.
  2. Flurry posted back in July 2020 that it intends to comply with Apple’s requirements so as not to require opt-in. In particular, they’ve explicitly said “Flurry will respect Apple’s policy requirement to not combine data across apps and websites owned by other companies.” It’s not clear how Apple would verify this is true, and this is surprising given Flurry’s business model, but it seems like a clear statement that Flurry intends to comply.
  3. A couple folks has asked if embedding code from YouTube – which certainly does ad targeting with its data – would violate Apple’s privacy rules. By the letter of the policy, this seems possible.
  4. Google has now joined Flurry in publicly disavowing tracking, which shifts the narrative towards these SDKs probably being allowed come iOS 14.5. Still, the wording of Apple’s App Privacy labelling UI makes this somewhat unclear.

2.8.21.1554

Accent Accent

Allen Pike • January 19, 2021

Release Radar: Ora

A few months back we heard from a very cool digital commerce company called Ora Organic. They ticked all our boxes:

  1. They care deeply about user experience
  2. They have enthusiastic customers
  3. They wanted to invest in building a very nice mobile app.

What better way to send off 2020 than by shipping a modern digital commerce app?

Meet Ora

Since 2015, Ora has been building a business selling nice plant-based supplements. They’ve built a name for themselves in a highly competitive space using data-centric decision making, the power of Shopify, an obsession with customers, and a clean but irreverent brand. In a space that’s sort of infamous for loud packaging featuring shirtless dudes promising GAINS, it’s hard not to be delighted by a clean, clear organic greens product titled “Easy Being Green”.

As a part of the growing subscription commerce revolution, Ora sees their customers very differently than your traditional consumer packaged goods company. Each transaction isn’t just about selling a bottle of product, but a contributor to a long-lived relationship with a given customer.

While a lot of brands can’t justify building a high-quality app just to facilitate a purchase a customer might make a few times a year or less, subscription commerce brands have both more frequent and more critical touch points as customers adjust and add to their subscriptions over time. Each pleased customer that’s happy to stay subscribed is worth their weight in organic chai protein powder.

The new Ora app for iOS

With that in mind, we worked with Ora’s excellent branding partners at Onbox to design an “MVP” Ora app that brings the clear and crisp Ora user experience to mobile – plus a couple cute animations. Then we used the excellent native Shopify Buy SDK to develop a modern Swift app that would be a clear win over the web experience, and built a foundation for delighting Ora subscribers for years to come.

We’d like to do a more in-depth case study of how we built the Ora app, and how we follow up with updates in the future. In the meantime though, you can be one of the first folks to check it out – it’s available for iPhone on the App Store today.

Download the Ora App Today

Download on the App Store

1.19.21.388

Accent Accent

Erica Leong • December 15, 2020

Case Study: Map of the Internet

Back in 2013, Peer 1 Hosting challenged us to build a cross-platform, 3D interactive map of the internet in 3 months. After being featured on CNN, accumulating over 100,000 downloads, and receiving an average rating of almost 5 stars, the Map of the Internet was one of the first apps to prove our mettle as cross-platform app developers.

We’ve now given that story a home. If you’re curious how we built and launched a map of the internet, we have the case study for you.

Read the case study

12.15.20.95

Accent Accent

The work and times of the app development team at Steamclock.

Archive (41) RSS Feed

Interested in future posts or announcements? Subscribe to our feed.