Trying to bypass the 30% Apple/Google Tax

Oh yes, this is where we are now. This is a thing nearly every single developer in the world, gets to deal with at some time in their "developer-life". Aaaaand here I am. In this blog I will tell you about what I've been doing for the last week, and how this is a big deal. Because it is a BIG deal.

This week's progress

Of course I'm going to drag you through the progress, before getting to the real meat of this blog post. If I do say so myself, this week I've been PRODUCTIVE! With the first half of the week procrastinating about the payment solution, I have been doing a lot of some "smaller" tasks. With quotes around smaller, because one of them being a revamp of the login screen and system. Some other small tasks, was fixing some irritating bugs. Last but not least I've added payment in the app now, I'm still working on finishing it, but payment is done.

New login screen

First of all, I've done the good ol' revamp to the UI itself, as I did with the rest of the app last week. But the biggest change here, is actually to what's happening behind the scenes. With an updated and more robust way of handling errors, and most importantly notifying the user of what's happening. It is still not perfect, but I do feel a lot better about releasing this than what it was before. The UI look haven't changed that much, but I have added essential features like a "Forgot password" option and progress indicators when logging in.

The forgot password page actually wasn't as big of a problem as I feared it would be, this is where I really think AWS Amplify shines a lot. When taking a look at how little code you can do this with, It's absolutely amazing what Amazon have done here. Taking comments and empty lines out, all the logic for changing the password fits in 60 lines. This code sends an email with a confirmation code, and then checks this code and changes the password. But actually a lot of this code is UI code, like showing a snackbar confirming that it have send the code. Taking all of that code out also, there's now eight lines left, although this code could fit in two lines, it's more readable in eight.

The next big thing happening with the login screens, is the new progress animations. Using Flutter's amazing feature, the animated container, I can change the size of a container and Flutter will animate that change automatically. These animations are purely for showing the user, that something is happening behind the scenes. They don't show how long it is, but we don't need that here. Take a look at the animation below.

Payment system

This section will only be about the payment system I have implemented this week, not about the Apple/Google taxes I told about earlier, that will come later in this blog. Getting that out of the way, I'm very glad that I got this system working this week. Using Stripe to provide the payment system, it have been a lot easier than I anticipated, still a challenge don't get me wrong. To make a payment system secure, there's a lot of things you have to keep in mind. Should we just take a look at it?

Backend handling the connection between Stripe and the app

When the user is starting a transaction, the app will send the necessary information to a Lambda function in the cloud. This information is the user's e-mail, the price and currency. This function will then contact Stripe, by first checking if there's a user in the system with that e-mail. This is done to allow the system to remember a user's credit card. If the user doesn't exist they will be added to the system. Once this have been done, the function will create a new transaction in Stripe, and send this transaction back to the app. The app will then use this information to contact Stripe directly. The reason that the app can't just contact Stripe directly, is purely for security. The app could by itself contact Stripe, but this would need the Stripe secret code to be stored somewhere in the app. If someone gets this code, they could easily use someone else's credit card stored in Stripe. That's why this code is stored securely, and all this is done purely in the cloud.

Frontend handling the connection between the app and user

Of course, you can't make a purchase without the user putting in payment details. This is also a point where Stripe has got my back! They've created an easy to use and beautiful UI for handling the payments. You can see this UI below. As you can see, this also takes Apple Pay on iOS and Google Pay on Android, which only makes these transactions easier and quicker for the user's! Just FYI, Apple/Google Pay don't use the taxes that I'll be talking about later, these taxes are only applied to in app purchases, on the contrary these don't use any fees at all, they're totally free to use.

Handling invoices

I'm still working on handling invoices, but this should be done in the next week! I'm working on integrating the accounting software API with the app, with the goal of course being that everything is done automatically. This wasn't as straight forward as I hoped, but the people at Billy (the accounting software), are very helpful right now. There will definitely be more on this in the next week's blog.

Bug fixes

This I will do very shortly and just copy the list from the changelog for this week.

• Fixed a bug causing recordings uploaded the same day to be shown in random, non chronological order.
• Fixed a bug causing the app to crash when typing a wrong activation code.
• Fixed a bug causing the settings page on some devices looking weird.
• Fixed a critical bug causing the app to upload file with wrong key and then that file wouldn't be accessible on other devices.

Taxes

It's a thing most people hate to pay, but we undoubtedly need as a society (I won't get too political). But taxes are mostly something we associate with governments, but the taxes I'm talking about are not. They are the taxes, or the cut, that Apple and Google takes when you sell something in an app, downloaded from their stores. I'm sure most of you already know how this works, so i will make it as short and concise as possible.

How does this work?

This tax is at 30%. It should be notet that you can decrease it to 15%, if you have a revenue under $1 million/year. Although this is a little different on Google's platform than on Apple's, with Google resetting this every year, so you only have to pay 30% of all the revenue over $1 million. While Apple is taking the full 30% on everything, from the day you're reaching the $1 million, and this won't reset the next year. So Google is taking an approach much like the danish "topskat", and Apple is just taking full price once you get the title of being a big business.

Why not just use other payment systems?

Glad you asked, if you're bored some day, you should read the App Store Review Guidelines, it's a sad and expensive novel. Long story short, the guidelines states that all purchases made in apps should use in app purchases. This does have some exceptions, and I'm just going to focus on two of these.

3.1.3(b) Multiplatform Services

This one is interesting, because this means that I can make a website, where users can add a payment method and use that in the app. And if you read last week's blog, you know that I am in the process of making a web version of the app. But this also have some caveats... You can't redirect users from the app to the website. You still have to offer in app purchases that uses the 30% tax.

3.1.3(e) Goods and Services Outside of the App

This one is actually made for apps like Zalando, where you can buy clothes (or other physical goods). BUT since it states "services that will be consumed outside of the app", I theoretically could twist this in my favor. This is because Speak's actual product is the Word document you get, this is what you pay for. All the services there are in the app, is totally free to use, but converting an audio recording to a Word document is the product you pay for.

Asking Apple for help

I did the responsible thing, asking Apple themselves for help, if anyone knows Apple's guidelines, it should be Apple. Being part of Apple's developer program you get a broad range of tools to develop apps for Apple devices. To use Apple's own words:

"And request code-level support from technical support engineers, so you can fix a bug, implement a specific technology, and get your questions answered."

I would think this means they will help you make the right decisions, on how to implement something like payments. But let's take a look at the answer I got:

Oh well... "We can't provide preapproval or guidance on app ideas or concepts", and the proceed to tell me to implement the technology I see fit, and cross my fingers they will agree. As both an Apple costumer and developer, I'm definitely not feeling that I get the support they're selling in their marketing material. The support I'm paying $99/year, to put it into perspective, the same tools and a more helpful support from Google costs $25 ONCE. Well I guess I'm just gonna have to try, it's worth a shot.

Are they going to accept this?

To be honest, I do not know, but I do take the precautions I can. I'm starting out by implementing Stripe as a third party payment in the app. I will then try to get the app accepted without in app purchases, and if that doesn't work i will give in. But not easily! Luckily we have a big company like Epic Games, fighting for the rights of developers. I would definitely recommend going and reading about this, because this is definitely something there should be more focus on!

You can get an overview of the case here: Epic Games v. Apple - Wikipedia

Beta release date!

Surprise! Yes I'm soon (hopefully) releasing the app in open Beta. The date is below, and is purely based on the assumption that Apple and Google will accept the app. I'm hopeful that this is going to happen, but there's definitely no certainty. I'm crossing my fingers.

DATE: February 18, 2022

But of course, this is a Beta release, which means nothing in the app is perfect! Although it will cost the full price for people downloading the app, you do have the chance to be a tester. Testers will be able to use the app and transcribe everything they wan't for free! BUT they of course will have to provide extensive feedback on the app. If you could use Mellonn Speak in the coming months, I would love to hear from you!

**Contact me on [email protected]

Please provide your name, email (the one you wish to use in the app), what you do and wish to use Mellonn Speak for and lastly, how much you wish to use Mellonn Speak.

See you in the next week

That's all for this one, it was definitely a big one this week! With big announcements and a pressuring topic for many developers around the world. Thank you so much for following me on this journey, and I will hopefully see you again next week!