DEV Community: RevenueCat

An iOS developer's guide to Apple's Fiscal Calendar (2024)

Peter @ RevenueCat — Fri, 12 Jan 2024 15:22:53 +0000

If you have an iOS app, understanding and planning around Apple's fiscal calendar is key to effective financial management.

This is a concise guide to help you plan your financial year effectively.

Understanding Apple’s Fiscal Year:

Apple's fiscal year typically runs for 364 days, segmented into four quarters.
Each quarter includes one 35-day fiscal month and two 28-day fiscal months.
Roughly every five years, an extra week is added to the fiscal year to align with the 365-day calendar year.

Developer Payment Schedule:

Apple generally pays developers 33 days post the end of a fiscal month.
Exception: The payment for the November fiscal month might be processed earlier, possibly for financial reporting purposes.

Fiscal Year 2024 Payment Dates:

October 2023: Payment due December 7, 2023
November 2023: Payment due January 4, 2024
December 2023: Payment due February 1, 2024
January 2024: Payment due March 7, 2024
February 2024: Payment due April 4, 2024
March 2024: Payment due May 2, 2024
April 2024: Payment due June 6, 2024
May 2024: Payment due July 4, 2024
June 2024: Payment due August 1, 2024
July 2024: Payment due September 5, 2024
August 2024: Payment due October 3, 2024
September 2024: Payment due November 7, 2024

Additional Points to Consider:

Apple's fiscal calendar and payment dates are generally consistent worldwide, though local bank processing times can vary.
Unlike Google, which pays developers on the 15th of each month, Apple has a distinct 33-day post-fiscal month schedule.
To receive payments, ensure a valid Paid Applications Agreement, proper banking information in App Store Connect, and adherence to the minimum payment threshold for each region.

For more detailed insights and additional resources on managing your app revenues and staying updated with Apple's fiscal policies, check out our comprehensive blog post. This summary is designed to provide you with the essentials, making it easier to manage your finances and plan ahead effectively.

Google App Campaigns for Developers: A Quick Guide

Peter @ RevenueCat — Wed, 28 Jun 2023 10:59:17 +0000

Google app campaigns (GAC) are a critical tool for app promotion, allowing developers to increase app visibility across Google's inventory, including Google Search, YouTube, Google Play, and the Google Display Network. However, getting the best results requires more than just a set-it-and-forget-it approach. In this guide, we'll cover the key insights developers should know to make the most of their GAC.

Tip 1: Understanding Campaign Optimization

Remember that the conversion event you choose directly influences how Google's algorithm optimizes your campaign. Depending on your app’s objectives, you can choose anything from installs to in-app events such as purchases or subscriptions. Be careful to choose a high-funnel event for new campaigns and then gradually move towards lower-funnel events.

Tip 2: Creative is King

Creatives are key to the success of your campaign. Consider using a mix of formats and sizes, including landscape, portrait, and square formats. Don’t shy away from using text, but keep it short and snappy. Google's algorithms will mix and match to find the best performing combinations, so experiment with different variants.

Tip 3: Localization and Internationalization

Localizing your campaign not only means translating the language but also adapting creatives to cultural nuances. The more you tailor your ad to local audiences, the better results you'll see.

Tip 4: Budget and Bidding

Bids are set per event, so a higher bid means your ad will be served more frequently. However, to ensure effective learning and optimization, Google recommends spending at least 10 times your target cost-per-install (CPI) per day.

Tip 5: Performance Monitoring

Use tools like Google's API, third-party partners, or specific reports to monitor campaign performance. Spend time analyzing the "campaigns" tab for more granular insights. Remember, the more data you can gather and analyze, the better.

Tip 6: Measuring Incrementality

Google app campaigns use a “modeled” conversion system, which may or may not accurately reflect true performance. To ensure actual impact, it's recommended to run incrementality analysis or use media mix modeling.

Tip 7: Search Keywords

Although GAC doesn't allow you to select or report on specific keywords, you can use negative keyword lists to exert some control. Moreover, understand that a significant number of conversions may come from searches on your own app name, inflating campaign performance.

Tip 8: Pre-registration Campaigns

Promoting your app before launch is possible with Google's pre-registration campaigns. However, be mindful of the budget allocation as pre-registrations may not convert into actual installs later.

Tip 9: Other Considerations

Ensure your campaign structure and location settings are well-optimized to avoid spreading your budget thin or attracting unwanted inventory. You may also consider running "video only" campaigns or using Firebase for audience exclusion.

In Conclusion

Google app campaigns, while offering tremendous potential, require a strategic approach, patience, and continuous monitoring. By choosing your optimization carefully, experimenting with creatives, and diligently analyzing performance, you can turn GAC into a powerful tool for promoting your app.

This tips blog is a summary of our definitive guide to Google app campaigns — so if you're looking to delve deeper, check it out!

RevenueCat now supports Unity Package Manager

Toni Rico — Fri, 10 Mar 2023 09:21:25 +0000

At RevenueCat, we believe that making our SDKs as easy to use as possible is of paramount importance. Developers need to have a great experience and be able to start earning money without any of the headaches associated with the stores.

One of the first things that developers need to do is to install our SDK in their app. Each platform has different systems. For Unity, our SDK has always been distributed as an asset package (a .unitypackage file). Now, we are glad to announce that, starting on version 4.6.4 of our SDK, we have added support for Unity Package Manager (UPM) and have set it as our preferred distribution system.

We are using OpenUPM as the registry for our dependency. You can find more details on how to install our SDK using UPM in our installation docs.

Using an asset package vs Unity Package Manager

First, we should understand the differences between both distribution systems.

Asset package

To summarize, asset packages are compressed files containing Unity assets, such as images, textures or scripts. This container can be imported into your Unity project, which will add all the assets to your assets directory. This is a relatively simple import process but it has its downsides, like:

No version management support. A .unitypackage doesn’t have a concept of version so it’s more difficult to keep track of the current version, update the dependency, and other common tasks.
No dependency management support. It doesn’t provide any system to set up a chain of dependencies if you depend on other packages.
Dependencies live alongside other assets. This means developers can accidentally modify the dependency in ways unintended by the authors.

The asset package file for RevenueCat can be downloaded from our Unity SDK Github repo releases page and you can just import it into your project, which looks like:

Figure 1. Importing the RevenueCat Unity SDK as an asset package file.

Unity Package Manager

Unity Package Manager is a system released by Unity back in 2017. It’s based on npm and it allows the distribution of packages through a package registry, where these dependencies are published.

This distribution system addresses the downsides of .unitypackages by providing version management support, dependency management support, and separating the dependencies from the rest of your project (among other advantages).

Package maintainers can distribute packages using options such as npm’s registry, creating their own registry, or using OpenUPM’s registry. Then, users of a package just need to add the registry to their project which will allow them to see and install all the packages there. You can find more details on how to do this on our Unity SDK installation docs.

At RevenueCat, we publish our package using the OpenUPM registry. You can add this registry to your project in your Project Settings > Package Manager section.

Figure 2. Importing the RevenueCat Unity SDK using Unity Package Manager.

As you can see, an asset package has the advantage of being simpler to import, but has several downsides when you want to distribute a software package — downsides that UPM manages to solve. At RevenueCat, we offer both distribution systems, so developers can import our SDK as they prefer — though we recommend using UPM.

The migration process

We’ve been distributing our Unity SDK as an asset package for a while, so now we will explain the process we had to follow to support UPM. We followed Unity’s documented process.

Adapting our code to support UPM

We wanted to make sure developers could use our SDK as a UPM package but we also wanted to allow them to continue using it as an asset package if they preferred. First of all, we had to add a few things to make our SDK compatible with UPM:

First, we added the package manifest with the information of our package, like version number and changelog links.
We added some assembly definition files to the folders containing the scripts of our SDK. This allows developers to access the scripts in our package in a much more organized way.

That’s it! Now we could start distributing our package. Pretty easy right? Well, not quite yet. We had two more problems to solve:

Our SDK’s dependency, Google’s External Dependencies Manager for Unity (EDM4U), is not available through UPM.
We want to make sure we test both distribution systems to avoid any regressions. This was not straightforward.

Google’s External Dependencies Manager for Unity (EDM4U)

Our SDK has a dependency with Google’s External Dependencies Manager for Unity (EDM4U). This is used to resolve our SDK dependencies with our iOS and Android SDKs on each respective platform.

Google officially only supports distributing this dependency as an asset package and they don’t distribute it officially in any package registry available through UPM. When we distribute our SDK as an asset package, we also include the EDM4U dependency within the package but adding this dependency through UPM was trickier due to the lack of UPM support from the library.

For now, we are asking developers to download the EDM4U asset package and add it to their project when they use our SDK through UPM. This can have problems if the specific EDM4U version doesn’t work with our SDK. We plan to add some functionality to the Unity Editor to download this library and make sure it matches our SDK.

Testing both distribution systems

Part of our engineering culture is to make sure our code is reliable, and automated tests are an intrinsic part to make sure that’s true. Since we are supporting two distribution systems, we need to make sure both work as expected.

Some of the things we need to test are making sure our SDK can be imported successfully as an asset package and through UPM, and making sure our API is accessible and functional when using either system. In our Unity SDK, we have what we call API tests. These tests make sure the API of our SDK can’t be changed by accident. Since we wanted to offer both distribution systems, we had to make sure both systems had reliable API tests.

In order to run API tests, we have to add our package to a Unity project, call each method in our API and make sure the project compiles correctly. Additionally, to create an asset package, we need to add the assets that belong to the package to a unity project and export it from that project. That means:

We need a Unity project in order to export the asset package.
We need a Unity project to run API tests with a project that imports our SDK as an asset package.
We need a Unity project to run API tests with a project that imports our SDK from UPM.

Before adding UPM support, we already had the first two projects. Note that we can’t reuse the same project easily since adding the same sources multiple times to the same project would cause collision errors in Unity.

After adding UPM support we had to either create a new project that used UPM or reuse the existing projects. Additionally, since we recommend using UPM, we wanted our main development Unity project to use UPM to import the SDK, to make sure we were using the same as developers use.

We decided to reuse the existing projects to avoid creating extra unnecessary projects. Currently our setup consists of two projects:

Subtester
- This is the project we use to test our SDK.
- It imports our SDK using a local package through UPM (this means we get access to the latest changes in the SDK immediately).
- We run automated API tests in this project.
- We use it to export the asset package to be used by the other project.
IntegrationTests
- It imports our SDK using an asset package generated from Subtester.
- We run automated API tests in this project.

The Subtester project does a lot of things. This project uses the SDK through UPM, so the SDK sources are not part of the assets. The issue is that in order to be able to export an asset package from this project to be able to distribute it as a unitypackage file, the sources need to be part of the assets of the project. In order to do this, we created a script that runs during our automation processes. This script:

Adds the SDK sources as assets of the project.
Removes the UPM dependency with our SDK. This is necessary, otherwise the project won’t compile since it will have duplicated sources (from the assets and from UPM).
Downloads the latest version of EDM4U and adds it as assets of the project.
Finally, it creates an asset package with our SDK and EDM4U included.

The IntegrationTests project is pretty straightforward. It’s a simple project that includes our API tests. When running automated tests, we import the asset package generated from Subtester beforehand and then compile iOS and Android projects that include these API tests.

Distributing our package: OpenUPM vs npm registry

Another decision we had to make when adding UPM support was where to publish our package. Our investigation led us to two popular registries: npm’s official registry or OpenUPM’s registry. Both are very popular but we decided to publish in OpenUPM for now. Reasons for that are:

OpenUPM has automations to automatically detect new versions of the SDK released in Github, so we can avoid adding automations to publish ourselves.
OpenUPM is oriented towards unity developers, whereas npmjs is more broad.

We might revisit this decision in the future or maybe even publish to both.

Have any feedback?

In this post we described the process we followed in order to add UPM support to our SDK. We are excited for you to try it out! Please let us know if you have any feedback as it greatly helps us to improve our SDKs.

How we migrated our SDK docs to DocC at RevenueCat

Andy Boedo — Mon, 06 Mar 2023 11:46:12 +0000

Early in 2022, we migrated our documentation for iOS at RevenueCat from Jazzy to DocC, and we wanted to share the reasons behind the switch and the process we went through to make it happen.

Why move to DocC?

At RevenueCat, we were interested in DocC since it was announced at WWDC ‘21. It seemed like a promising format, with a clean look that’s familiar to any iOS developer, and lots of potential for documentation that truly guides the reader.

Our docs were previously generated using Jazzy, a great open-source library. While we never had issues with Jazzy, Apple’s DocC promised noticeable advantages when compared to Jazzy.

Here are a few of the reasons why we decided to make the move to DocC.

Format and navigation

DocC allows you to organize the information for the reader, allowing for a nicer introduction into what the SDK does. Most doc generators simply show you a main page and access to all symbols, so new readers don’t know where the entry points to the SDK are and how the symbols relate to each other.

This however can easily be done with DocC: you can generate Topics and better organize the docs. This way, the symbols can be cleanly organized into logical sections, like “Configure the SDK” and “Displaying Products”, instead of a disorganized list of all the things the SDK can do.

The resulting documentation is more readable and the overall design is more polished. It even supports Dark Mode!

But you don’t have to take my word for it. Check out the last version of docs we generated using Jazzy and our current version using DocC.

Checking for linked symbols

This was ultimately what made us make the jump to DocC: we wanted to have a clear way to know if we have a symbol linked in our docs that’s out of date.

There is a Build Setting in Xcode (RUN_DOCUMENTATION_COMPILER) that allows DocC’s compiler to generate warnings if a symbol in the documentation doesn’t match the source code, which helps ensure that our documentation stays up-to-date and accurate. This is covered more in detail later in this post.

IDE integration

Figure 1. DocC integrates seamlessly with Xcode.

Another big benefit of DocC is that it is backed by Apple, which means it is well-supported and integrates seamlessly with Xcode. The docs generated through DocC look the same as the ones you get when you select “Show Quick Help” (or ⌃⌥+click on a symbol) in Xcode, which makes it a lot easier for us to ensure that the Quick Help section looks correct and is easy to read.

Future improvements

Interactive Tutorials look really promising, although admittedly we haven’t created our first one of those yet. We’re looking forward to trying them out!

Apple has been hard at work improving DocC and adding features to it, including a Swift Package Manager plugin and the ability to easily host DocC docs in GitHub Pages.

How we migrated without stopping development

1. Update our docs to common format between Jazzy and DocC

Our first priority when deciding to try out DocC was to retain the ability to make releases and generate documentation while we’re still migrating docs.

The first step towards this goal was to update our documentation so that its formatting was compatible with both Jazzy and DocC’s formats. This was important because it allowed us to easily switch between the two while we were testing and making adjustments.

Luckily for us, Jazzy adopted most of the format conventions that DocC uses, so updating our docstrings to DocC format was easy to do.

Figure 2. Jazzy adopted most of the format conventions of DocC, making updating easy.

2. Enable DocC documentation compiler to fix typos in symbols

Some of our old docs had typos in the links to symbols in the SDK. We set the build setting in Xcode called RUN_DOCUMENTATION_COMPILER to Yes, which compiles docs when you build the project. This step is thankfully very fast (~0.2 seconds for our SDK), and it adds a build warning if a symbol isn’t correctly referenced. We used this to clean up our docs.

Figure 3. When compiling documentation in DocC, warnings are given when symbols aren’t reference correctly.

3. Take advantage of DocC’s power

Once we had basically the same docs generated with DocC instead of Jazzy, we could truly start to work towards making them more useful. One of DocC’s best features is the ability to organize the docs into Categories and Topics, allowing for a clearer structure.

This allows us to design the flow of information that a reader first sees when going into our docs, to make it as easy to navigate as possible.

Figure 4. DocC allows you to organize docs into Categories and Topics.

4. Hosting in GitHub Pages

We moved the documentation into GitHub Pages and set up a CI job to automatically generate and deploy the docs with each release of a new SDK version.

When we started working on this it was a lot harder to do because you needed to export an archive of the docs from Xcode and then do some work on top of them to publish them. But, thankfully, Apple added support for exporting for static site hosting.

Apple has a tutorial for how to host docs in GitHub Pages, so we won’t duplicate it here, but the basic command is:

Figure 5. The command for publishing docs to GitHub Pages.

We also added a fastlane lane to preview the docs locally so we could check for formatting errors before publishing a new version.

5. Versioning

While we love DocC and at this stage we have a pretty clear picture of how to publish docs, there’s one problem that DocC has no answer for: having different versions of docs for different versions of an SDK.

Ideally, we would want a version selector that you can use to navigate to the version you want and you’d be directed to the latest version by default.

However, there’s no way to achieve that using just DocC.

Instead, what we did was:

Create a new folder which has a subfolder per version of the SDK.
Host all the docs in a new repo, so that versions are independent of branches in the source repo. This allows for us to develop on one branch while the docs repo gets updated for latest releases separately.
Create a new page that redirects the user to the latest version of docs if they navigate to the root of GitHub Pages.
Add a step that updates that redirect page in CI when there’s a new release to make it point to the corresponding new version of the docs.

You can see how this is structured in our docs repo here. The corresponding CI job is located here in our source repo.

Conclusion and future

DocC has been a big improvement for our SDK Reference Docs at RevenueCat. While we’re happy with the result, there are a few things we’d like to do in the future:

Introduce interactive tutorials for our main use cases.
Add a version selector (please, Apple, add support for this!).
Introduce a language selector to be able to see the Objective-C docs (hopefully coming soon!).

The actual migration path was thankfully not difficult, because Jazzy is compatible with most of DocC’s format. And we can now rest assured that the symbols referenced by our SDK are correct.

Take a look at our SDK Reference docs and let us know what you think!

What’s the best way to monetize kids apps?

Peter @ RevenueCat — Fri, 24 Feb 2023 14:51:30 +0000

Choosing the most appropriate monetization strategy is of fundamental importance to all apps, regardless of intended audience or function. But apps for children stand out as being uniquely challenging, often in ways that aren’t immediately apparent.

We’re not going to cover all of the challenges facing kids apps — that’s for another post. But there are three which have a huge impact on monetization (as well as on overall design) in this category.

Kids apps are heavily regulated — in terms of data management, analytics, and advertising.
When you’re building a kids app, you’re designing for two user groups : the kids and the parents. And unless you establish parent trust , they’re not going to pay.
Kids have an insatiable curiosity and can be difficult to keep focused and engaged. And unless kids are engaged, parents aren’t going to see the value.

On the Sub Club podcast, we’ve interviewed two kids apps creators: Melissa Cash & Félix Boudreau from award-winning preschool app Pok Pok; and Brennan Clark from Sago Mini, which offers three subscription apps for preschoolers (and has seen over 100 million downloads).

What stands out within these conversations is the strength of the subscription model when it comes to monetizing kids apps. So through the lens of these three key challenges facing kids apps, and supported by the experiences of Pok Pok and Sago Mini, we will outline why kids apps makers should be looking to subscriptions.

Navigating child privacy guidelines

“We wanted to create the absolute purest experience for kids from day one. That has been challenging to be honest, because there are tricks of the trade, which I’m sure a lot of the people listening know about in order to make more money. But, from the very beginning of our journey, we wanted to make sure we’re starting with a clean slate that’s creating the most value for the child first.”

Melissa Cash, Pok Pok

The kids app space is, quite understandably, heavily regulated — as is all media aimed at children. For instance, there’s the Children’s Online Privacy Protection Act (COPPA) in the US, the Children’s code in the UK, and General Data Protection Regulation (GDPR) in the EU. These regulations, together with the subsequent app store guidelines (Apple’s and Google’s), heavily restrict what data you can collect and transmit in your app, as well as what content you can show to kids.

How does this affect monetization?

These regulations make it extremely difficult (and, in many cases, impossible) to make monetization models like in-app purchases or advertising work. The tactics that are used to make money from these are often manipulative or pressuring — such as frequently gating progress until an ad has been watched or a purchase has been made. These pressuring tactics are strictly against the rules. And children are especially susceptible — according to NN Group: “Because kids’ ability to plan and execute is still limited, they are more vulnerable to attractive games and may develop addictions to games or apps easily.”

As for advertising, while in general it isn’t entirely prohibited, the third-party networks you can use are restricted to ones which comply with Apple and Google’s rules. Also from the NN Group in a separate UX study: “On a more negative note, children still don’t understand the web’s commercial nature and lack the skills needed to identify advertising ** ** and treat it differently than real content.”

Sadly, despite these regulations, a worrying amount of apps don’t seem to be complying. A 2022 academic study found that “a majority” of apps used by 160 children aged 3 to 5 years “were associated with manipulative design features.” These “dark patterns” (interactive designs that benefit the designer at the expense of the user) include things such as making the user undertake tedious activities unless a purchase is made or disrupting the user during daily activities to return to the app.

Separately, a 2022 Pixalate study found that many thousands of apps across Apple and Google’s stores don’t comply with COPPA regulations.

Children’s Privacy Risk Scorecard

Privacy regulations — for kids and adults alike — are only ever going to become more strict in the future. Subscriptions, meanwhile, can help app creators continue to grow and make consistent revenue, while still remain compliant — and not resort, as these studies have shown, to trying to get around the rules.

Building parent trust

While you may be designing an app to be used predominantly by children, it’s not them who are going to be paying for the privilege. So you’re designing for two separate user groups, both of whom have different goals and expectations.

To convince parents to pay for a kids app, they need to see:

what value the app is going to bring to their kids
that their kids are actively using the app (and deriving that value)
that the app is trustworthy and is safe in the hands of their kids

Whether or not a parent believes an app will deliver value is somewhat dependent on their own outlook (clearly, apps that focus on education and development have an advantage here). And to see long-term value, kids need to be kept engaged — we’ll be coming back to this shortly.

But crucially, none of this matters if an app doesn’t build trust with parents. How do you build parent trust? Avoiding “tricks of the trade”, with which most parents are going to be intimately familiar, is a great start.

“ Subscriptions have unlocked a bit of additional trust in that there is no sneaky stuff.

We’re not doing in-app ads. We’re not doing a bunch of IAPs, gems, all this type of stuff. We have a single subscription price. Parents can lock that in or just enjoy the free experience. And having that kind of safe, trusted environment for their kid is another really big selling point for parents.”

Brennan Clark, Sago Mini

Sago Mini World

Sago Mini also builds trust with the style of content they provide: “[Make] sure it’s interactive. It’s not this passive…YouTube-kid style of content. That’s been a really big thing. Parents love that. Parents trust that.”

And for Pok Pok, not only does it find that the subscription model builds trust with parents, but so does adding a paywall right at the beginning of the user journey:

“We’re asking parents to commit right away to a subscription. We do offer a free trial because it’s very important that the kid can try the app and actually see if it’s a good fit… But at the same time, like Melissa said, *we’re betting on parents who value having a very pure experience where there’s no paywall, there’s no sneaky game mechanics that the kids might fall into and then they get that crazy bill because of in-app purchases. We’re against that 100%. *

And also I think it’s beneficial for the parents because… we want to create something that the child can play with without the parents being involved… A side effect with paywalls in a freemium version is that the kid’s going to run into a paywall. At two to six, he might not even be able to read… so he doesn’t know what’s happening.”

Félix Boudreau, Pok Pok

Trust comes when parents are confident that the app maker has their kids’ best interests in mind — and when the monetization model is hands-off and easy to navigate.

Keeping kids focused and engaged

Pok Pok

And finally, even when you’ve built trust, if the kid isn’t engaged and deriving value from the app, then nor will the parent see the value in paying. Once again, the subscription model supports the kind of content creation needed to keep the experience fresh and interesting.

“We knew that we wanted to create something that was always evolving…because kids are so curious… So we knew we had to create new content regularly and we also had a million ideas… And in order to do that, we need recurring revenue. So a big piece of the why came from that. It was just like: we know we want to make more content over time, so we should be a subscription. ”

Melissa Cash, Pok Pok

Keeping kids engaged is only half the battle. The other half is making sure the parent knows it. One way Sago Mini achieve this is by building a separate app for parents:

Another thing that we did was we launched a parent app as well…when their kid is drawing something or doing a coloring sheet in one of our apps, there are artefacts that are actually sent to the parent app. And so that’s this nice touchpoint that reminds the parents of the value that their kids are getting.

Brennan Clark, Sago Mini

In short: kids apps should look to subscriptions

Subscriptions aren’t necessarily going to work for all apps, and they may work well in combination with other monetization methods in a hybrid approach. But subscriptions play well with strict child privacy regulations, build trust with parents, and provide consistent revenue that allows regular content creation.