It feels a bit awkward. After all, it's been just slightly over a year since we released a fully-revamped version that enjoyed mesmerezing reception from the developer community. A hard decision that we think is best for Gikken –  focus all our energy, resources, and time on one thing that's performing the best and showing the best potential for becoming a big business – Mate Translate – our flagship product.

We didn't want to merely shut Tokens down as we know how valuable you find it. Tokens has been enjoying the love from app developers, marketers, and customer support fellows for the long 7 years. You, guys, generate hundreds of thousands of codes every month that help you acquire more subscribers or build better relationships with existing customers. We couldn't simply take that away.

We spent the last 2 months trying to find a successor who would share our view on privacy, great design, and the importance of community. We're happy that our paths crossed with Adam. He's ramping up his portfolio of SaaS products for app developers and considers Tokens a good fit. He bets big on the importance of Tokens in App Store's future with third-party payment methods.

So what's next?

We'll transfer the ownership to Adam next week. There's absolutely nothing that will change for you. We'll transfer your subcription to Adam's Paddle account. App auto updates will keep functioning. All tokn.co links and the Mac app will stay intact.

It was a deal-breaker for us that the successor is big on privacy just like we are. Once the handover is through, we'll remove all Tokens-related data from our servers. Adam will ensure to follow the high security standard we've set for Tokens.

We'll keep assisting Adam for the next two months until his team gets comfortable with supporting our code base and App Store Connect's API, so they can guarantee fast response in case of issues.

Thanks everyone for being Gikkeans! And many thanks to dozens of people who helped us shaping it to what it has become.

Team Gikken 💜

It's hard to describe how happy we are at Gikken—our little software baby will live on! Even though it stopped making sense for us business-wise, we never stopped loving Breaks for Eyes. It's terrific news for us that it has landed in good hands.

Breaks for Eyes will be available on https://breaksforeyes.app and the Mac App Store.

As of Feb 9th, 2021, the following text is outdated. Leaving it here for the sake of transparency.

We use computers every day. We stare at them for hours on end. Screens envelop us! In October 2018, we created Breaks for Eyes to counter Computer Vision Syndrome and ease eye strain. It was a simple tool that matched up perfectly with our mission to make people's days brighter in a small way.

...we must discontinue it on February 19th, 2021 to focus on our other products...

Despite its elegance, Breaks for Eyes did not pull enough profit to sustain itself and we must discontinue it on February 19th, 2021 to focus on our other products. Gikken has matured greatly over the past year and we gradually came to understand that our attention cannot be spread thin. To create as beautiful and impactful a product as Mate Translate, we must fully dedicate ourselves to it and not be distracted by other projects that do not capture enough interest from our community. Mate is approaching 1 million monthly active users—we don't want to ignore this. We want to feed the flame, making Mate the very best it can possibly be.

We know many folks still use Breaks for Eyes daily and encourage everyone to carry on their healthy ocular habits. Hopefully our little app has inspired some to walk away from work and wake up to the world around them every so often—it's a wonderful exercise in mindfulness.

Thank you for taking breaks with us. Stay in the moment. Look around and soak in your surroundings. Most of all—take care of yourself.

Team Gikken

Check out our popular, super-versatile translator: Mate Translate

Gikken has matured greatly over the past year. We gradually came to understand that our attention cannot be spread thin. To create as beautiful and impactful a product as Mate, we must fully dedicate ourselves to it and not be distracted by other projects that do not capture enough interest from our community. Mate is approaching 1 million monthly active users—we don't want to ignore this. We want to feed the flame, making Mate the very best it can possibly be.

We built Reji in May 2018 to accompany Mate as a language learning tool. There was a burgeoning market for flashcard apps and we knew we could design the best if we followed our brand ethos of beautiful, functional, minimal tools that cared about user privacy while relying on our own transparency.

At its height, Reji had 25,000 language learners building their vocabularies across 48 popular languages. We were delighted to hear success stories across Twitter and in emails from users. As multilinguists ourselves, we cherish this small contribution to a large community of self-learners. Unfortunately, there came a decline. Duolingo's Tinycards shut down not so long ago. We attempted to divert their lost audience to Reji to no avail. The edu category is tough enough to break into! Now here we are, having to make the tough decision to decommission one of our core products.

We know there are many folks out there still using Reji every day. Don't stop learning. Pick up Mate to translate wherever you are. Take language courses. Read books, watch movies, and have casual conversations with native speakers. You'll be speaking another tongue before you know it.

Thank you for learning with us.

Team Gikken

***

What happens next?

As long as Reji is downloaded on your phone before we shut it down, you'll be able to access it indefinitely. You will not be able to re-download it again as it will be removed from the App Store.

Reji will be removed from the App Store on March 31, 2021.

Sharing decks, uploading custom images, and CSV import will stop working.

If you're an active user, you'll want to export your decks to a CSV to import elsewhere or keep handy in case you find another learning solution.

If you purchased Reji in the past two weeks, you can request a refund here.

In the next 15 minutes, you’ll find out how to maximize visibility of your app by…

1. Making students your best ambassadors
2. Leveling up your PR
3. Getting more attention with Giveaways
4. Rewarding loyal customers
5. Cross-promoting your apps

But first, let's quickly clarify the code diversity:

Offer vs Promo vs Introductory vs Promotional Codes

It's alright to be confused. I was too. There are 4 different App Store code types as of now, and they serve different purposes. I studied Apple's maze of docs, so you don't have to, and explained it in simple words.

What are Offer Codes, First of All?

They look like this: FMWPN78P7TTHLW3MKE (quite long, yep). You can share them with a prospective subscriber, so they redeem the code, and get your subscription with a time-limited discount.

What's particularly great about offer codes is that you can adjust literally everything: how much $$$ off your regular subscription price you want to offer, for how long they'll be paying the discounted price, and finally, for how long your offer will be redeemable.

It’s safe to call Offer Codes the most versatile marketing tool offered by the App Store since its release in November 2020. You can use them to attract new subscribers, win back the churned, or retain the existing. Limited at 150K codes per quarter per subscription, you'll barely feel a shortage. I doubt those who will are reading this 😁 And, Tokens will help you carefully dispense those codes—one per user—so you squeeze the most revenue out of that quarterly limit.

But we've already had promo codes...

Not quite the same thing. The difference is as vast as that between Apple Calendar and Fantastical. Both offer and promo codes can be distributed outside the app via QR codes, on blogs, in ads, on social media, etc. Users can redeem them via App Store or convenient tokn.co links. Promo codes always give a 100% discount, i.e. if you give away a promo code, a person will get your subscription for free for its entire duration. Say, you have a $9.99/year sub. Give a promo code to this sub, and they will get 1 year for free. That's it—no other options.

With offer codes, you set your own rules. 30% off your $3.99/month subscription for 2 months? You got it. Free access to an annual subscription for 1 month? Not a problem.

You can generate just up to 100 promo codes per subscription per 6 months, whereas offer codes are limited to 150,000 per quarter per subscription!

Such a steep difference is easily justifiable by what you want to use these two for. Promo codes are good for driving extra sales indirectly. Send out free copies of your app to influencers and journalists. If they like and mention it, you'll get extra downloads that are yet to be converted into subscriptions. Offer codes are more about helping you to convert potential subscribers directly, without the influencer middleman. You wouldn't reach out to 150K journalists, would you? However, you may have that many potential customers.

Last but not least: promo codes expire in 28 days after generation, and offer codes—when you decide (max. 180 days).

"I've also heard something about Introductory and Promotional Codes..."

Yes, that's a thing, too. However, their marketing potential is rather limited as they can only be distributed within your app, so forget about running a 50% off giveaway or sending a free copy to that Italian Apple journalist using these two.

If you're more into comparison tables, here's one from Apple itself:

Let's Translate Those Codes into Revenue

Although I'm not a business mastermind who created apps that would be making billions of dollars like Tinder, I hope that a few strategies from my arsenal may be handy for fellow developers. They helped us at Gikken grow our best-in-class Mac and iOS translator app—Mate—4x in the last 2 years. We're a bootstrapped three-person company and we're careful about every dollar we make and spend. I'll be very happy if any of my takeaways will help you make more off of your awesome app!

Note: I'll be using Tokens in my examples—the app that we made to help you generate offer and promo codes faster, and your users redeem them with ease—by just clicking on a link.

1. Making students your best ambassadors

Many of us know firsthand that students are on a tight budget. However, it doesn't mean they don't deserve good software. For years, companies have been adjusting their regional prices according to purchasing power. You can think of student discounts as an even more caring income-based price adjustment.

On the upside for your app business, students are some of the most socially active folks out there. They meet a lot of people in classes, their dorm, at parties, etc. Make them your loyal users and you may get your best ambassadors. That surrendered 30% of your sub price will pay off over and above in new users they'll bring in. People love bragging with things they love. If your app is good (and I'm sure it is!), take down the price hurdle for students, so they can start loving it, and spreading the word.

When we launched a 50% discount for students and teachers on Mate, it took off instantly. Many students were discovering Mate but couldn't afford it. An easy-to-get discount took out this barrier. Now, edu sales account for around 15% of our revenue.

It's worth mentioning that in order to make it work like a charm, you need to automate it. It makes sense to test whether there's interest for your app among students by just directing them to your support email first, but it won't scale. It will hold back too many from claiming it (too much effort: come up with a message, write it, attach a student ID, wait for a reply, redeem a code). On the opposite, typing in a student discount and instantly getting a discount is totally frictionless and as fast as it just could be. No emailing or waiting involved. You sell it to them the moment they want it. Also, you certainly don't want even more emails in your support inbox.

Here's how we made it with Mate: user enters their student email, we validate it using this fabulous library from GitHub, and if it's actually .edu, send a discount code to that address.

Whether you go the easy way, and offer discounts via email support, or the harder but more efficient way—automate it. You may find Tokens helpful in dispensing those discounts.

Apple made creating offer codes a two-step story: they are stored in campaigns, or just offers. You set up an offer once and then you generate codes for it. You can top it up with more codes at any time.

First, I want to include one static link into my student emails, so it dispenses codes automatically—one per student. On the screenshot below, I create an offer that gives 50% off my subscription for 1 year:

Then, I want to add 1,500 codes using that + button:

Now, I can copy the offer link and include it in my student emails:

I don't have to mingle with managing a database of codes, picking unused ones for each email, generating and re-uploading new codes every now and then. It all runs smoothly without my attention now. Using Tokens's redemption status, I will know when I need to top up my student campaign. Then, I'll just hit that + button and add a few more thousands of codes.

2. Level up your PR

It's old news that a few powerful folks can multiply your reach by thousands. In other words, get an influencer to like your app, and they might share it with hundreds of thousands of their readers. How do you get them to like it? You show it to them. If you can run into them at WWDC, perfect—do it in person. If you can't (and in 2020, you can't), send them a friendly email (aka pitch) explaining why their readers must love your app.

The key to any good pitch is playing up how easy it is to test the product. Influencers and journalists get dozens of requests like yours. Even if the pitch is half-baked but it's super easy to play around with the actual product and the product is super good, you up your chances by a lot. Since subscription-based apps are technically free, they can test drive it for free, true. If they seriously want to write about you, they'll need access to all features, though. Including a promo code when sending out a pitch has always been a good tone. And offer codes aren't changing anything fundamentally here. The good part is that you have 15,000 times more offer codes than promo codes, so you'll barely feel short of them. Also, giving a promo code meant that the journalist would get your premium version for the entire duration of the subscription. With offer codes, you can easily adjust it.

My jaw dropped after we made our interview with Ryan Jones who 50x'ed traffic for Weather Line with Tokens. The power of doing good PR is often undervalued.

To start blasting out my pitches, I want to create an offer—free 1 month trial:

Add a bunch of codes by clicking that +, and then I can copy a code, and even name it not to forget who it went out to:

Let's keep the fingers crossed:

OK, actually, I'll know for sure whether my titanic pitching efforts have paid off:

3. Get more attention with Giveaways

It's no big news that people love free or discounted stuff. They stand in hour-long lines, click links for it, upvote and repost it. Remember Black Friday: people hoard discounted goods while companies report sky-high revenues. I'm not suggesting that you must take part in the consumerist hysteria that takes place on a gloomy November Friday. I'm very skeptical about it myself. But speaking in marketing slang, giveaways are an efficient way to increase your brand awareness. It's similar to ads in some way. You sacrifice a chunk of sales to get more exposure. Get more people to know about your app and hope that some of them become your fans and will recommend it to the others (virality!).

• Jump on a mainstream discount bandwagon like Black Friday, Cyber Monday, etc.
• Celebrate a major update with a major giveaway. You can also partner up with one of the bigger blogs like iMore to pull it off. Or, just drop it on Twitter. Here's one example that is still generating retweets and likes, and thus new eyeballs for Ryan's stunning game.
• Give away discounts or free copies at conferences. This way, you can get influencers on board that will keep spreading the word about your awesome app. I picked up this idea from Frank Rausch who prints out QR codes with a Tokens giveaway link and gives out his beautiful Wikipedia client to his students.

As you see above, Sindre is also using Tokens. A great opportunity to pull in free impressions is not going to be there forever. Tokens is designed so you never miss those.

Sindre was giving away free copies. With offer codes, you decide whether it's going to be free, 10%, 50%, or 90% off. Absolutely anything is possible now.

Your only goal is to make as many people as you can open that tokn.co link. Distribution is on Tokens. It will carefully dispense one code per person.

I don't want to be judgmental on whether it's good or bad to run promotions all the time. There are different opinions in this regard. Some say that if your product is good, you don't need to stimulate customers with discounts, they'll buy it anyway. However, for some good products—e.g. Babbel—jacking up prices and then running discounts works well. Personally, I adhere to the first category more. We at Gikken try to limit any kind of discounts to the absolute minimum (a few per year), and drop them absolutely randomly so that people don't get used to it, or wait up until we drop the next promo.

4. Reward loyal customers

Subscription business is tricky because the selling process doesn't stop, even when a person is paying you. At that point, your new goal is to maximize LTV. In other words, make everything, so they don't unsubscribe for as long as possible. Forging a good relationship with your users is one way to do so.

There are two things that we gladly reward our customers for: participation in interviews and help with troubleshooting issues. If you're ever interviewing your users to make roadmap decisions or improve the UX, it'd be a mauvais ton not to reward them for their time and insights. A juicy discount on the subscription they're paying is low blood for you and definitely pleasant for them. If someone's spent their time to get through the tech maze to help you debug a pesky issue, why not show them your gratitude by giving a discount?

Even though Apple lets you only generate offer codes in batches of at least 500, Tokens lets you conveniently copy single codes, too.

We align with Apple on the importance of user experience, so we had to fix their totally monstrous "L4FNTF7MN8YYX6H6XY"-like codes. If you send a Tokens-wrapped code, your customer will get an easy-to-unwrap tokn.co link, like this:

5. Cross-promote your apps

If you have multiple apps like us, there's literally no excuse not to leverage the existing user base to cross-sell your apps. I don't mean spam users of app A with app B until they purchase the latter. But it's pretty likely they love app A so much that they might be interested in purchasing more apps from you. You've already earned their trust. Leverage it. Make it as easy for them as possible to learn more about you and your other products.

We made this mistake ourselves. We used to market every app as an independent product. It's significantly harder than keeping them under an imaginary umbrella of company's brand. For us, it's the Gikken-first approach now. Maybe, my company is not the best-known example. Here's a better one: Playdate by Panic. When guys announced their funky yellow handheld crank-supercharged console, it became an instant hit even before pre-orders. Would it be such a hit if we announced and not Panic? I severely doubt so. More likely, people would think, "WTF, a Gameboy with a crank in 2020? You're nuts." Panic used their existing fan base very efficiently. Why start your marketing from scratch if you can use what you've been earning in the past years, and reduce your marketing cost and effort to almost zero...? Exactly, no reason. This concept is also called 1,000 True Fans, which I'm a true fan of.

What does it all have to do with offer codes? You can use them to reward existing subscribers of app A with, say, a 10% discount on your app B. Create a Tokens Offer, and embed a "Claim Discount" link to app A that'd open the tokn.co link. Easy to top up and keep track of how many offer codes were used! Forge better relationships with your customers and win them as true fans.

Here's an example I personally like a lot on how to showcase your other products in app settings, taken from Kriss Smolka's HealthView:

Why Do I Need These Tokens of Yours If I Already Have App Store Connect?

It's surely up to you what to use, mate. Gikken ain't Facebook to force someone into something, after all. Using ASC in this case just feels like trying to code an iOS app in Assembler, though. Tokens way feels better than SwiftUI, sex, and cold beer altogether.

So you don't think I'm lying, here's how you do with via ASC: sign in → choose My Apps → choose an app → Manage In-App Purchases in the bottom left column → choose a subscription → click on + next to Subscription Prices → Create Offer Codes → go through a 6-step setup process. At the end, you'll get a .txt file with codes. Copy a code from the list, insert it and your app ID into the following link, so people can actually redeem it: https://apps.apple.com/redeem?ctx=offercodes&id=APP_ID&code=CODE

On the other hand, Tokens pairs with your Apple ID, so you don't have to re-login every time and have all your apps and subscriptions neatly organized in the sidebar. Select a subscription and click "Create an Offer." You set up an offer campaign once, and these settings will apply to all codes you add into it after that. For example, here's how easily I can create a Black Friday Giveaway campaign that will give my customers 50% off their first month:

And then I can add offer codes into my campaign. Tokens maxes out the expiry date at 180 days. Offer campaigns never expire. It means you can use up your limit of 150,000 codes per quarter, and next quarter add another 150K to the same offer campaign. Extremely handy if you want to keep that giveaway tokn.co link continuously alive. Say, if you embedded it into your email automation, for example. Just keep adding new codes every quarter and you're covered.

Tokens lets you share both single codes and the whole offer campaign. Either way, you'll get your codes wrapped in a tokn.co link that's easy to redeem for your customers. If you decide to give away a lot of codes, you'll still get just one link that you can share with everyone—Tokens will carefully dispense codes, one per user.

And, here's my absolute favorite endorphins generator: redemption status and notifications. Tokens will notify you whenever a code gets redeemed. It's off by default because of the numerous nature of offer codes. We don't want to get you accidentally spammed with 500 notifications. Turn it on in preferences if you feel like knowing about every redemption.

That's it! If you want to give Tokens a try, you can download it here. Our free trial is time-unlimited and lets you generate, share, and track 500 offer codes and 10 regular promo codes.

Feel free to reach out to me/Gikken at [email protected] or via Twitter with Qs or suggestions. I'm always happy to help fellow devs.

If my artsy wallpapers caught your attention, they're from our other app called Artpaper.

Disclaimer: the app that appears on all screenshots—Learn Spanish & French Verbs—is actually owned and developed by Kevin Quisquater who kindly gave us access for testing purposes. Neither he nor the app is affiliated with Gikken.

Back when we launched at the beginning of September, our pricing model was app-based instead of code-based. That meant a huge customer with one app generating 1000s of codes would've been paying less than an individual dev with multiple apps generating dozens of codes.

Now, you get what you pay for—rather, pay for what you generate.

What we mean by fair

The three of us at Gikken are no adjudicators of fairness. What's fair to one is completely unfair to another, despite that going against the supposed nature of fairness itself—that it should create equilibrium.

It is impossible to be fair when discussing value because value is entirely relative. What we can be, however, is honest. Transparent. Understanding.

We can listen to your feedback and actually change shit. Get it done. Not just sit on our paws pushing out more bug releases and polish. You can only polish so much until your app erodes away completely.

The old price versus the new

Before today, you'd have paid around $4/month per app with unlimited code generation. Yeesh!

Going forward, you'll pay $3.99/month for unlimited apps with a 50 code max or $7.99/month for unlimited apps with no code limit.

Multiply by ten for the annual rate:

We added a little crown to the unlimited plan because devs who dish out that many codes should be coronated. Y'all are generous!

Fortuitous feedback

We can't thank enough all the Token folk who were bold enough to be blunt with us about our original pricing model. Many of you reached out via Twitter DMs and email and we encourage you to continue doing so!

It's one thing to connive your way to cheaper or free apps from indie devs—that's dreadful. But it's entirely welcome to write generously constructive thoughts on how your favorite products can be improved.

You can see right through us

Our main aim with this pricing rethink was to make Tokens 2 comfortable for our users. Comfort includes not being left in the dark—comfy as darkness may be—and we're here to be real with you.

Would we have made more money with the original pricing? Possibly over time. Or we could've scared off folks for whom the dime was a bit too high.

Price-logic-wise, this is a classic case of luxury product with few customers vs affordable product with many customers (there's probably a proper marketing term here).

Gikken-logic-wise, we're not here to take your metaphorical kidneys. As long as Tokens 2 can continue to serve the dev community and put dinner on our tables, we're delighted.

Any decent company should align its pricing models with its product value props. Any good company should listen to its customers. Any fantastic company should be totally transparent about why changes were made, divulge motives, and rhyme with chicken.

Yours frugally,

Team Gikken

8 months ago, I shared exciting news that we bought Tokens from another developer. Being a financially successful indie developer focused on language learning tools, we felt that we wanted to try a new area, to solve problems for a new community. When I started using Twitter over a year ago, I figured out that Gikken's brand had been underrepresented in the developer community, being a 5-year-old company. Could there have been a better match than to make a product for developers? We didn't think long when an opportunity to acquire Tokens popped up.

Today, I'm thrilled to announce that Tokens 2 is out. It's an all-new version of the app that was once a marketing and customer support powerhouse for thousands of Apple developers.

Acquisition

I discovered Tokens last year—later than most Apple developers. It was love at first sight. Having promo codes always at hand saved me hours of customer support work. Redemption notifications triggered dopamine even when redeemed by ordinary users, let alone popular bloggers!

Gikken-owned Tokens happened quickly–it amazes me. I asked whether Denis planned to make an iOS app. He replied maybe, Andrew and I offered to partner up and make it together, and Denis got back offering all the rights to it.

It took us one call to decide. Denis turned out to be a super friendly guy living close to Dublin, Ireland and making apps for a living for over 10 years. He said he took over Tokens from another developer, Supertop. 7 years after the app was first released, it hadn't brought in any revenue. Denis said he didn't do any marketing and Tokens's monetization model was the worst imaginable fit for a small B2B market—low-hanging fruit. We decided to give it a shot. Money aside, it was an amazing opportunity to spread the word about Gikken among developers.

A few days later, we signed a one-page agreement. We have never mentioned it but Denis threw another project into the deal: Top Hat. We'd acquired two products. After we wired the money, Denis messaged me on Christmas eve to say he had free time and could hand over access to all repositories and accounts. I was in the office, why not. Gikken took full ownership of Tokens on December 25th, 2019!

Interviewing old users

Even though to us it was obvious that Tokens had to be able to generate promo codes for IAP in 2020, we wouldn't have jumped on it if people hadn't cared about it. "Winners learn from losing," yet doing something that no one cares about demotivates even the winners.

The best way to figure out if people care is through user interviews. I had to interview app developers to figure out: how often they use promo codes, for what, how much of a pain was App Store Connect, would they be ready to pay for it, and how much. Andrew once sent me a copy of The Mom Test–one of the best business books I've read. It teaches you how to conduct interviews that won't give you false hopes.

It wasn't hard to find people for interviews. Denis handed us over the full list of everyone who's ever purchased a Tokens license. No one can tell you more than someone who's purchased a product once. They know whether their workflow became better with Tokens and whether it was worth the money.

It was fun looking through the list. Surprising that a lot of iconic developers were among users. Developers of Flighty, Things, Pixelmator, Waterminder, Fantastical, and 1,000+ others once believed that Tokens could improve their workflow. In early January, poking around the old customer list replaced Instagram as a way of procrastination.

I started timidly approaching people I'd heard the most about. I thought why the heck not, they might ignore me or not, at least I can say I tried. To my surprise, everyone who I was reaching out to ecstatically got back to me.

The first interview was with Ryan Jones from Flighty and Weather Line, which was a goldmine of insight and motivation. Tokens 1 didn't support promo codes for IAP. All Ryan's apps are freemium, however, he was an active Tokens user. He was pulling codes from ASC and inserting them into the app manually to have nice tokn.co links and redemption notifications.

I could tell Ryan was interested in Tokens's future by the amount of his questions. It was me trying to figure out how he uses promo codes and it was him trying to figure out what would happen with his favorite product.

When I started using Tokens, I instantly noticed that I was missing it when I was away from my Mac. I couldn't generate a code to quickly share with someone on Twitter. We discussed the idea of making an iOS app with Andrew even before we finalized our deal with Denis.

Ryan told the same. I felt relieved when I heard that my experiences align with those of a another user. I told him about our plans: that Tokens 2 might be a cross-platform app that would synchronize via a Tokens Account and that you would use Sign in with Apple. He asked about privacy. I said Gikken's adamant about it and that we would never store user credentials on our end—due to lack of the official App Store Connect API, we have to use user's Apple ID to make requests for pulling codes from Apple. He was excited. Following the call, Ryan kept helping us to shape the pricing strategy and UX.

I held around 15 interviews with users of the old Tokens in January. I approached people who I'd heard about because they were pretty influential in the community or those who were using desperately-outdated Tokens 1. I brushed up on my SQL skills to pull a list of them from the DB. A few generously agreed to jump on an hour-long call with me and others answered my questions in details over email. It provided a boatload of feedback and insights that we then had to process and shape into Tokens 2. All interviewees are now featured on our Credits page.

There were people who said they didn't need it anymore or that they'd quit the app business. Many things can happen in 8 years. We had a strong impression that, all-in-all, Tokens was a much needed tool. As I mentioned before, reviving a once cult-like product would go hand-in-hand with working with the amazing community in which we wanted to be more recognized. We had to relaunch Tokens with long-overdue features, rethink the pricing model to make it viable, and finally convince the community that were the right company to do so.

Before doing work

We did planning and thinking. Do we need to rewrite the app from scratch or slap new features on top of what we'd inherited from two prior developers? How much should it cost? Does it need to be on the App Store?

App Store vs self-distribution

• 30% cut + taxes would mean we have to give up half of our revenue, which would barely make it viable again. In interviews, developers were pretty aligned on all things pricing–something between 5 and 10 dollars per month was fair to them. Considering the small market, getting 2.5 dollars out of 5 didn't feel like a fair justification for spending resources of the redesign and maintenance.
• App Store invoices are bad. Developers have registered businesses. They need to submit invoices to their tax offices. We do it every month and we understand the importance of unobtrusive, easy-to-find invoicing.
• It wouldn't give us any spotlight value that Apple claims to give. Who on earth would look for a better promo code management system (we checked–no one). It's not an obvious thing that people learn about via word-of-mouth and it's not something they open the App Store for.

We went with Paddle. We've been selling Mate with them for a while and it's proved itself as a perfect solution for selling Mac apps, plus it handles taxes, invoices, and licenses for you at a modest 5% cut.

If we were to port Tokens to iOS, we'd have to use the App Store. The whole Tokens for iOS story was pretty controversial from the beginning because it was giving access to Apple services without their approval (remember, there's no App Store Connect API). Chances they'd reject us were pretty high. We thought we'd test the waters by trying to submit Tokens 1 to the Mac App Store. It would have required poking around the old ObjC code and sandboxing it—we never went through with it. Instead, I got reassured by Ariel from Appfigures and Vadim from NativeConnect who successfully made it to the store with their apps that did the same thing as Tokens–use App Store Connect in a way not approved by Apple. A positive App Store review is an approval, isn't it?

The iOS app would rely on the Mac app in a way that it'd be a "reader app". You'd manage your subscription and create a Tokens account via Mac app, and the iOS app would allow you to sign in with Apple to your existing Tokens account and have access to your promo codes and generate new ones. Sounds like a perfect Netflix-Spotify-inspired 30% cut avoiding scheme for a service that doesn't need App Store's spotlight value that Apple claims to provide.

From the ground up?

It was up to Andrew who's written almost all the code for Tokens 2. Since the original Tokens was written in Objective-C (we entered the app business when Swift was  announced—it's not hard to guess what our preferred tech stack is) and used pretty outdated APIs (made in 2012!), he said we should. Plus, we had to change everything for it to support accounts and IAP codes.

It was tempting to try fresh-released (back then) Catalyst to avoid making two separate apps for Mac and iOS, yet there were more cons than pros and we went old-school–good ol' AppKit. Andrew was adamant that we couldn't keep torturing ourselves with NodeJS on the server anymore. He set up a nice REST API architecture with Kotlin + Jetty instead. We moved the database from PostgreSQL that was used in the original app's backend to MongoDB that we've been using since the first day at Gikken.

Pricing

It's always the toughest. Despite a common misconception, lower prices almost never drive more sales. If a complex, well-designed product is priced low, it's suspicious. Why? Is it a rip-off? How can a well-designed app that takes months or years to develop cost $0.99?

The price tag must perfectly reflect the value the product offers, in other words, how much of a user's time it will save or how much money it will help them make. If the price is not slightly annoying, it's too cheap.

There were two questions that I asked every interviewee: "What's the lowest price you'd pay for Tokens without thinking we've compromised on quality?" and "What's the highest price you'd reluctantly pay for it?" It gave us a certain price range: 5 to 10 dollars per month.

Delighting old customers

We hadn't told anyone that we'd bought Tokens nor that we had plans for its revival before we processed all the feedback from interviews. With the groundwork ready, it was time to finally announce to over 1,000 people who once purchased a Tokens license.

I drafted an announcement for Gikken's blog and made an alpha version of Tokens's current website with basic information like who we were, what our plans were for Tokens 2, a rough release timeline estimate, and a beta sign-up form. Initially, we thought we'd release Tokens 2 both for Mac and iOS in June. Today's September 1st. Guess whether the first estimation was correct 😁 The work in public began on January 24th when all customers got the email from us. It was nice to get  extra motivation in replies to our announcement–people were happy to see that their favorite tool was getting a much needed update.

Redesign

I was dreaming about designing a perfect Mac app ever since we released Mate for Mac. We did an amazing good job with it but it's a menu bar app and its power lies in little integrations rather than swept together in a NSWindow. In my head, I was imagining an app that'd look like it was baked into macOS from the start but would still have its own spirit. It had to be simple yet powerful like my two favorite default Mac apps: Safari and Calendar. Finally, my little dream could be fulfilled.

Not trying to be unique with custom UI elements has many upsides. It feels familiar to users. They don't have to re-learn basics like where to find a back button or what happens when they click on a pull-down menu. We all got sold on OS X/macOS partly because of its clean, easy-to-understand design. Apple designers have thought many things through and shaped the system's design to be consistent across all apps to minimize any learning curve.

Designing by macOS guidelines comes down to reading the instructions (HIG) carefully and putting together "LEGO bricks" to get the functionality you need. Speaking of HIG (human interface guidelines) and grass was greener rhetoric, when I did the  first tweets about the upcoming Tokens redesign, Mario Guzman was kind enough to share Apple's old OS X guidelines with me. They're not only better than what Apple has now, they should be in a handbook for all interface designers regardless of platform. If you take a glimpse at it, you'll understand why–it's a 400-page manual that describes everything from margins, to hierarchy in interfaces, to differences in different locales.

Yet another reason  Tokens 2 was destined to be built with default elements is development speed. Drag'n'drop, LEGO-style. Andrew is happy about it.

Even though designing by guidelines is putting together Sketch Symbols from the macOS Design Template, it's the designer's job to design the UX. How to display promo codes: as a list or gallery like in the old Tokens? Where should the Generate Codes button be? How to display apps?

At Gikken, we find it important to design for users instead of showing off in front of other designers and developers or pleasing our ego with over-engineered products. We got all answers to whether there was something wrong in the old Tokens from user interviews. Interviews are multi-functional. No questionnaire or analytics tool gives as much insight into everything as a good in-person chat. I can't say Tokens is a complex app—it's pretty simple, yet there were things that were annoying developers or that they didn't even know existed on the feature list.

• Apps were displayed as icons without names. Things has 3 versions of their app–for Mac, iPhone, and iPad. The latter two have 100% identical icons. Guess how many times Mick and Julia from Team Things mis-clicked those two. Countless! Another reason the old gallery view wasn't a good fit is because Tokens 2 had to introduce support for promo codes for in-app purchases. A collapsible sub-list was a match made in heaven. We converted the app list into a separate list and tucked into the sidebar, similar to mailboxes in Apple Mail.
• One thing that no developer has mentioned in interviews was Giveaways. The original Tokens allowed people to group promo codes into a "folder" that would be available by link and one user could redeem  one code. Super useful if you want to share more than one code with a group of people or do a giveaway on Twitter or Reddit. It was  deeply hidden in Tokens 1 that I didn't even know it existed when we bought the app. The app owner didn't know about all its features. Funny, right? We decided to give this feature one more chance. We implemented unlimited giveaways in Tokens 2 and supercharged them with  extra organizational features like color tags (hello, Finder).
• The old Tokens could  generate a pre-defined number of codes: 1, 5, 10, or all available. Given the promo codes' tendency to expire within 28 days, it may be inconvenient when you  need 7, for example. We designed a better generation menu that lets you select any amount you want. A simple slider that made a huge difference to our beta testers.
• "Copy" is the most popular action developers do with promo codes. In the old Tokens, you had to right-click on a code to copy it via the context menu. In Tokens 2, it became a one-click action.

Gearing up to beta 1

While I was tossing bars, buttons, and list views around in Sketch, Andrew was writing the back-end infrastructure. It needed a lot of changes given the new features like unlimited giveaways, accounts, and IAP in Tokens 2,  he  wrote it from scratch in Kotlin+Jersey+MongoDB.

As soon as we announced Tokens 2 to the public, our marketing machine started working. The main goal was to encourage as many people as possible to wait for the release day with excitement. We had a  good foundation with the legacy customer base but then we had to make them excited about Tokens 2 and  attract new people to the waitlist. Old Tokens customers were  from 2012–2014, a lot of new faces have entered the app development since then. Since there was  no competition to Tokens, we decided we could afford the luxury of being  transparent about everything, from numbers to early mockups to detailed progress updates.

It may come off as an easy task at first, but it wasn't. For me, it was  a venture out of the comfort zone of product work. We know how to make good software but we've never been active in content creation. Suddenly, it became an important part of Tokens marketing as our future customers are spending hours on Twitter. We had to post a lot of interesting things to keep people engaged and drive new developers to sign up for the waitlist.

The first months were tough in terms of content. Both me and Andrew had a hard time finding content to tweet about. I'm  inspired by other indie developers like Charlie or Shihab who have built impressive audiences  by  documenting their work on the bird site.

As we were rapidly moving forward with building the app and battling with our own introversion at the same time, beta sign-ups were slowly flowing in. Unfortunately, not at the rate we expected or were satisfied with, though. I assume, it was because we didn't share enough interesting content or because our first site didn't evoke much trust because it was, let's be honest, pretty ugly. When we reached out to the legacy customers, we expected we'd release the first beta in March for a limited number of active users and in May for those in the waitlist.

As it happens, the initial timeline didn't hold up. In March, we realized that the app was half-baked and we couldn't even use it internally yet. We moved the beta 1 release day to June 15th. No one complained, no one cared about it yet. As the app was coming together and we could  generate first promo codes by clicking buttons without hacking around in the Terminal, the content making machine geared up. One of the notable experiments that helped me to post more regularly was setting hourly calendar reminders that'd pop up with, "Hey, did anything interesting happen worth tweeting out?"

Shortly before shipping beta 1, we had around 150 people signed up for the waitlist. The site's  got upgraded from the ugly first version to how its current look. We thought that  our waitlist didn't turn out as long as Superhuman's because of the reach – it could  be  low given our fledgling Twitter status and  small audiences (less than 1,000 followers me + Andrew).

To cheat our way around it, we tried running Twitter ads. I used look-alike audiences of prominent developers like Marco Arment, John Gruber, and Felix Krause for targeting. It means our ads would show people who follow those guys and other people with similar interests, which is making iOS apps. Look-alike-audience-based ads were a big revelation for me a year ago when we were launching Artpaper for iOS. They're cheap (CPC as low as $0.10),  precise, and ridiculously easy to set up – you  write a tweet, throw in a few Twitter profiles, set a budget, that's it.

It did bring  awareness, new subscribers, and sign-ups for the waitlist, but we didn't feel it had groundbreaking results.  we never turned back to ads after dropping beta 1.

Beta 1 is out in the wild

Feelings on the beta release day were the same on release days of our other apps. We invited old users and people from the waitlist at the same time.  over 1,000 in total. They made amazing, award-winning apps themselves. It was thrilling to show our work to them. What if they told us that Tokens 2 was shit, unsubscribed, and we'd never get them as customers again?

A bad thing with emails is that the open rate will never be 100%. We were at around 60% when we announced that we started working on Tokens 2. , not everyone read it, people have  discovered that Tokens was getting revived when beta 1 was ready to use. They were surprised and thankful. All in all, we received a few dozens of emails. I was surprised to see feedback flowing in  a few minutes after I've hit Send.

We decided to take a  dev break (Andrew even went camping) for a week or two and wait until more feedback comes in, analyze it, and plan next betas and the release version. Pleasantly, the  feedback was  positive. , it was  minor UX quirks or bugs. Two  major things were an unintuitive position of the + button and Giveaways (then Campaigns).

At that time, it was  clear that tit would be impossible to release Mac and iOS apps at the same time while sticking to a date in the  near future. We decided that first we'd focus on polishing the Mac app, launch it, see traction it's going to get, collect more feedback, and then start working on the iOS app hustle-free.

New ways to get developers on the waitlist

Personal outreach

My occasional contemplations about how to get more people on the waitlist were getting me back to the idea that there should be something annoyingly manual. Inspired by how Tinder acquired "swipers" in its early days I started reaching out to developers and inviting them to poke around the beta manually. I aimed for 100 invites and ended up inviting around 90 developers over a few months. It was influencers and less prominent developers who  made apps that I liked. It was a lot of fun because I invited  people who have been following me and I've been following them for months but we never talked. Invites sparked a conversation and thus rooted the relationship. I wasn't asking for anything in return,  giving them exclusive access to a tool that could save them hours. It's  important to keep a good relationship with your existing and prospective customers,  with a community this small. Without bluff, it was our best marketing decision.

Talking Tokens

Another interesting experiment for ramping up awareness about Tokens and driving more waitlist sign-ups was interviews with developers. There were about 150 developers who were  relying on Tokens 1 in their day-to-day business. Yannick, one of our icon designers, said that he'd be interested to read "case studies" of what promo code gurus use Tokens for. Sounded like a great opportunity for both dev relations and marketing to us!

The pilot issue was with  Ryan. He told us about the far 2013 when he was launching Weather Line and promo code marketing helped him get 50x more eyeballs after influencers spread the word about his powerful little weather app. As we'd expected, the interview turned out to be a goldmine of insights about how useful and powerful promo codes can be.

I'm  happy that the Gikken team grew to 4 people around the time we were releasing the first Tokens 2 beta. Tom and Dave joined us in late May. While Dave was coding billing, Tom became in charge of all our content, including Talking Tokens. He talked with developers, shaped their words into beautiful stories. I don't think Talking Tokens would exist without his help.

Further betas

Undoubtedly, beta 1 was the most intimidating one for us to release. If we'd have screwed it up, it'd be hard to convince developers we were headed the right direction and they should further trust us. Initially, we scheduled beta 2 one month after beta 1, and then the final version. Beta 2 was supposed to include things that weren't  relevant to the core functionality like billing, nice-to-haves like beautiful animations, and bug fixes that we'd identify in beta 1.

However, we decided to release one more – beta 1.5 – to hotfix quirks, improve UX, and redesign Giveaways (Campaigns). It was fast work, we didn't want it to be postponed with all other bulk that we'd planned for beta 2, like App Updates, Billing that takes a lot of time to implement and test.

After reality has hit hard our initial out-of-the-blue schedule and we received first feedback from  users with beta 1, we could plan accurately. The new timeline looked like this: beta 1.5 – July 15th, beta 2 – August 10th, release – September 1st.

Since we live in the times when TestFlight is  exclusive to iOS, we did beta updates in a pretty blunt way – via re-downloading. We implemented a server flag through which we could mark betas expired, then the app would prompt a developer to download a fresh version (to avoid obsessive intrusiveness it was checked on app launch or a few times per day).

Gearing up to the release day

In the summer, Andrew was all into polishing Tokens 2 for the day, September 1st. I was doing my manual work, talking with developers, inviting them to check the future of promo codes.

We  needed support of the community on the release day and beyond. We needed every Apple developer to know about Tokens 2 and how life-changing it is even if they didn't need it themselves (e.g. they work at a big company and don't  use the App Store). It's helpful in the long term because if they'll ever be talking with other devs they might mention us if the promo codes topic pops up in their conversation.

Demo account

It was great to have support of influencers and press. Interestingly, not all developer influencers have their own apps. Thus, Tokens 2 would be  useless for them. They don't have what to generate codes for. We  wanted them to poke around the app, though. We created a demo account for them. It would generate fake promo codes (that looked legit, though) and wouldn't require them to have their own Apple Developer ID. The experience was 100% real. You'd get tokn.co links, they'd open App Store for redemption. It'd  fail because Apple wouldn't recognize the underlying promo codes. The demo account was pre-populated with our other apps, Mate and Artpaper.

We used the same demo account to show Tokens 2 to folks at MacStories. It's  every developer's dream to get featured there at least once. Not that one should lean back solely on it in their marketing, but it's a nice ego-booster + they're trustworthy. All Apple developers read it. We've never been covered by MacStories,  it was a fantastic feeling when we could finally catch their attention with our product.

#TokensGiveaway

3 weeks before the release day, three of us (me, Tom, Andrew) had a call in which we planned every tiniest detail we had to do pre-release: all remaining pitches, tweets, marketing imagery, bugs, videos,. Tom once suggested we should do a cross-promo with our developers. They'd give away a few copies of their app with Tokens, we'd give them a discount on our subscription. I was pretty skeptical at first – isn't it asking for too much... , I was underestimating our amazing community! When I tested waters by offering a few developers from the beta program to take part in our little initiative they gladly agreed. We tried our best to structure #TokensGiveaway in a way  it's a win-win to both parties, word of mouth for us, extra visibility for developers' apps + Tokens discount.

I can't be thankful enough to 30+ developers who have agreed to participate in #TokensGiveaway. In total, they're giving away $2,500+ worth of top-notch apps today, on September 1st. We're taking part with our Gikken apps. That's another $2,000+ worth of Mate, Artpaper, Reji, and Breaks for Eyes.

Browse #TokensGiveaway on Twitter!

Product Hunt

We launched 11 times on Product Hunt. It's become a tradition for us. Once, we were even nominated for PH's annual award, Golden Kitty, with Mate Translate for iMessage. PH community is as friendly and wholesome as our iOS/macOS Twitter dev community. We don't consider PH major sales driver. Andrew tried to convince me otherwise – as if there are a lot of developers hanging out on PH who might subscribe to Tokens. We'll see. We think of PH more as of a nice animation in your app that is more a nice to have rather than a major selling point.

Beers with Team Tokens

One more idea was born in our pre-release call. It should mark the end of Gikken's introversion and make us even closer to the community. Many go into podcasting to leave their social mark and improve the personal brand. We didn't have time to start a podcast, plus the market is doing fine without yet another podcast. We decided to make a livestream wrapping up these 8 months and invite fellow developers who have launched something recently to chat about their experience. Aidan Fitzpatrick from Reincubate joined us to tell about their launch of Camo, the simple app that turns your iPhone in a webcam, thus fixing shitty MacBook built-in cams.

The whole thing was recorded and published. We'll also single out small snippets of usefulness out of it later.

It was unobvious at what time to stream. I was advocating for the weekend, Andrew was for weekdays. In my opinion, people aren't busy with work on the weekend and they enjoy watching  football or F1, and Beers with Team Tokens is any different. We tried running a Twitter poll and asking around, and the public opinion was on Andrew's side, though. The best time for it was as late after work as possible, weekdays. Then, it was tricky with time because we have customers from all time zones. I had to go through all beta people who were supporting us the most and match up to their timezones. Everyone would  think they were in the US, right? Tech, Silicon Valley, all  that. To my surprise, Tokens users were in Europe. 2nd place – the US, 3rd – Australia/NZ.  we went for 8 PM CET which is  a reasonable time on both East and West Coast US. Unfortunately, in Australia, the sun will be taking first attempts to rise at this time. But... it will be recorded!

View the recording.

Meet Tokens

Useful links

• Download Tokens
• Learn more about Tokens 2 features
• Talking Tokens interviews
• Comparison of Tokens 1 and Tokens 2
• Follow Tokens on Twitter
• #TokensGiveaway
• Contact us

Credits

A huge thanks to everyone who advised us, shared feedback and ideas, reported bugs, used raw versions of Tokens, retweeted, liked, and was  following the development process.

You. Are. The. Best!

On October 31, 2019 Twopeople Software officially became Gikken.

Not because someone acquired us or invested in us (except for users, of course!). It was our seasoned idea of re-incorporation in Berlin, Germany. So, we just switched a legal entity for our business. It’s still me & my co-founder who are in charge of all decisions.

Let’s take a glance at Twopeople Software’s (TPS) history and then I’ll explain what influenced our decision to re-create TPS as Gikken in Berlin.

A very brief history of Twopeople Software

TPS started back in July, 2016. By that time, me & Andrew already made our first app together. Funny enough, we started working together after I dropped out of school, where we met in Kiev, Ukraine, and moved to Vienna, Austria. The first app we made was Mate Translate for Mac.

For almost one year, we didn’t have a legal entity and were trying to sell the app on the Mac App Store using Apple’s individual developer license. We weren’t making money, so there was nothing to pay taxes on (in case Finanzamt — the Austrian tax office— is reading this).

In 2016, I gathered a 4-person team of classmates. There was me, iOS/macOS developer, Android developer, and a Windows developer. We wanted to make the best translation ecosystem for all devices out of our then-only product Mate Translate. It may sound like a successful (or a VC-funded) team but we were neither of that. I offered everyone a revenue-share partnership — i.e. they’d get 40% of revenue from the app they were in charge of. After around a year of work, the money was still not flowing in, Android and Windows developers also lost interest. The TPS team shrank to just two people: me & Andrew who was previously only in charge of iOS and macOS apps.

And that’s how it still looks today. We went a long way together. We launched 3 new apps. We tried to sell hard-copy artworks. We hired people. We fired people. We tried to raise money. We found our uniqueness in being self-funded, so we advocate for bootstrapping now.

Why did we decide to move

When TPS stopped being a side-hustle and started taking shape of a serious business which requires our full-time attention, we committed to an idea that we want to be in the same place to grow the business.

I remember Andrew was visiting me in Vienna in May 2018, we were invited to Pioneers Festival — a major startup conference in Austria — a local version of TechCrunch Disrupt, if you want. That was the turning point when we decided that Vienna wasn’t a good candidate to host our HQ at all.

The main nags were: an incredibly weak software-making community and general conservativeness towards tech. I don’t want to be hopping on a plane every time I want to go to an iOS development conference or meet up with a successful developer from the community. So, we decided to pick another city. After all, we were (and are) young & flexible enough to be able to pull off a move hassle-free. It was a good chance not to get bound to one place and realize you’re unhappy at some point.

So, we started thinking about other cities where there would be a strong tech community (in other words, the more prominent software we like— preferably B2C — was made by a team based in a certain city, the better), a good life quality, its affordable cost, and, desirably, there would no visa requirements.

American cities like San Francisco or New York offer amazing opportunities when it comes to tech and innovation. However, for us as non-Americans, the first feasible complication would be relocation itself as we’d need a visa. Secondly, those cities are just too expensive. We aren’t living on VC dollars, though. So, we lined up major European tech cities: Berlin, London, Paris, and Amsterdam. They’re all equally good in terms of tech-savviness of people living there, and quality of life. We crossed the last three off the list because they’re just too expensive. Thus, we were left with Berlin. In our opinion, it offered (and still offers) the best trade-off between cost of life (appr. 2.5x cheaper than London or Paris or SF or NY) and the amount of tech-related stuff going on here.

Differences between TPS & Gikken

I’d put it this way: Gikken is a more mature version of Twopeople Software. It’s TPS with a clear(er) vision and values. At TPS, we went a long way from making browser extensions to macOS apps to iOS apps to an Android app to even a Windows app. At some point we got sold on the VC trend and wanted to raise money (the furthest we got was a few meetings with VCs and a Y Combinator interview). Generally speaking, we were making the first steps in software business and didn’t always know what we were doing.

The main difference though is that at the times of Twopeople Software the company was kind of a grey eminence. We didn’t bother to build company’s brand at all. Users who were using Mate most likely didn’t know that there’d been some company called Twopeople Software behind it. Obvious enough, if someone came to use Mate, they didn’t know about our other apps, either.

That’s bad for a bunch of reasons: if someone installs our app and likes it, they’ll be more likely to purchase our other products — thus, it decreases the customer acquisition cost and increases the chances of getting 1,000 True Fans — which is a good base for any business. It’s also bad in the long term run because we had to market every app independently — as if it were our first product, basically, even if our other product is loved by millions.

From now on, we market Gikken in the first place. It’s Gikken that made Mate, Reji, Artpaper, and Breaks for Eyes. And if we launch something new, you’ll be the first to know.

And this century’s main mystery… What does Gikken mean

Unlike Twopeople Software (which, obviously enough, means that 2 guys are making software), Gikken may sound a bit offbeat, as a made-up word. In fact, it is, but not in a way that a cat jumped on the keyboard and ‘gikken’ came out.

You’ve learned before that being offbeat is part of our strategy to stand out among all the “SomeEnglishWordsGluedTogether Software” companies. We wanted it to be concise and memorable. Hence, it couldn’t be an English word because all English words are already taken. We also wanted our new company name to reflect our core values and not be bound to any of our products. As the experience showed us, time changes very rapidly and projects we may be betting on now can be shut down some time later. We’re building a company to last, so the name had to be product-independent, too.

I was testing something in Mate once and noticed that many Japanese words actually sound irresistibly cool. Thus, we turned to the Japanese language. We started translating our core values from English to Japanese: quality, reliability, experiments, openness, transparency, etc.

These attempts yielded quite a good result — Jikken, which means ‘an experiment’. It sounds quite harsh but reflects our desire to experiment as much as we can, so we decided to go for it with a little modification. We softened it a little by replacing J with G. Coincidentally, a word ‘geek’ which also applies to us starts with the same letter.

Geek + Jikken = Gikken, Experimenting Geeks. G is pronounced as in GIF.

We’re a super transparent company, so…

at any time, you can ask us a question on Twitter, via other means, read more about us, apply for our job openings, follow Alex, follow Andrew, and of course, download our apps.

Intro:

We're working on Tokens 2 now, and it needs a robust REST API that's easy to update. We love using Kotlin for our APIs, since it provides a lot of modern syntactic sugar, while being based on Java, which has a ton of libraries available and is as reliable as it gets.

We were using plain servlets before, since our APIs weren't RESTful. This time we need to be able to manipulate all the objects from the client, so RESTful it is. We wanted something that's easy to write and lets us avoid writing boilerplate code every time. That's why we picked up Jersey for this task, as it allows to easily create standard GET / POST / PUT / DELETE interactions for data models, while also allowing for any customization.

We use Jetty for serving multiple web apps in our company. For the ease of use and deployment, Jetty is installed on our server permanently and we're not embedding it into the webapps themselves. All the config guides I found online told only the "embedded Jetty" story, which doesn't work out for our use case.

If you're like us a little – welcome to this guide, I'll take you through all the steps needed to make your API run in less than 30 minutes.

Guide:

1.   Create a Kotlin project. We use Gradle, but you can use Maven if you want. You can also use my template.

2.   Here's the list of dependencies you'll need in addition to your usual ones:

dependencies {    
	compile 'org.mongodb:mongodb-driver-sync:3.10.0'    
	compile 'org.litote.kmongo:kmongo:3.9.2'    
	compile 'org.litote.kmongo:kmongo-id-jackson'    
	compile 'org.litote.kmongo:kmongo-id:3.9.2'
	compile 'org.glassfish.jersey.core:jersey-server:2.30'    
	compile 'org.glassfish.jersey.containers:jersey-container-servlet:2.30'
    compile 'org.glassfish.jersey.inject:jersey-hk2:2.30'    
	compile 'org.glassfish.jersey.media:jersey-media-json-jackson:2.30'
}

3.   Create a web.xml at src/main/webapp/WEB-INF/web.xml

4.   Use this snippet to populate your web.xml. Replace the %%'s with your info.

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" id="WebApp_ID" version="3.0">
    <display-name>%%YourProjectName%%</display-name>
    <servlet>
        <servlet-name>Jersey REST Service</servlet-name>
        <servlet-class>org.glassfish.jersey.servlet.ServletContainer</servlet-class>
        <init-param>
            <param-name>jersey.config.server.provider.packages</param-name>
            <param-value>%%your.package.here%%</param-value>
        </init-param>
        <load-on-startup>1</load-on-startup>
    </servlet>
    <servlet-mapping>
        <servlet-name>Jersey REST Service</servlet-name>
        <url-pattern>/api/*</url-pattern>
    </servlet-mapping>
</web-app>

5.   We need to register a @Provider for the KMongo. It will ensure the conversion is seamless between the JSON objects and the KMongo Data Classes we will create next.

Create a KMongoProvider.kt and populate it with this code:

@Provider
class KMongoProvider : ContextResolver<ObjectMapper> {
    override fun getContext(type: Class<*>): ObjectMapper {
        return KMongoJackson.mapper
    }
}

object KMongoJackson {
    val mapper = jacksonObjectMapper()

    init {
        mapper.registerModule(IdJacksonModule())
    }
}

6.   Let's connect to the database and create a data model:

class Connect {
	companion object {
		val client = KMongo.createClient()
		val database = client.getDatabase("kotlin-example")
	}
}

data class Dog (
        @BsonId var _id: StringId<Dog> = newStringId(),
        var owner: String,
        var name: String,
        var bornAt: Int,
        var lastVaccineAt: Int?
) {
    companion object

	fun collection(): MongoCollection<Dog> {
        return Connect.database.getCollection<Dog>("dogs")
    }
}

7.   Now we need to have a resource for our Dog class. It will tell Jersey how to interact with the model and it will expose the model for the API access:

@Path("dogs")
@Produces(APPLICATION_JSON)
class DogResource {

    @GET
    fun listDogs(): MongoIterable<Dog> {
        return Dog.collection().find().map { it }
    }

    @POST
    fun createDog(token: Dog) {
        Dog.collection().save(token)
    }

    @GET
    @Path("{id}")
    fun getDog(@PathParam("id") id: String): Dog? {
        return Dog.collection().findById(id)
    }

    @PUT
    @Path("{id}")
    fun updateDog(@PathParam("id") id: String, dog: Dog) {
        dog._id = StringId(id)
        Dog.collection().replaceById(id, dog)
    }

    @DELETE
    @Path("{id}")
    fun deleteDog(@PathParam("id") id: String): Boolean {
        return Dog.collection().deleteById(id).deletedCount > 0
    }

}

The listDogs() method takes no parameters and uses the path we defined for the whole DogResource. The createDog() method takes a JSON that should match the data model, but without the _id key. Try to send wrong format of JSON to see how it behaves. The get / update / delete methods work on */dogs/{id}/.

8.   I use extension functions listed below to easily find / replace stuff by id. Create a DBUtility.kt and put the functions in it.

fun <T> MongoCollection<T>.findById(id: String): T? {
	return this.findOneById(StringId<T>(id))
}

fun <T> MongoCollection<T>.deleteById(id: String): DeleteResult {
	return this.deleteOneById(StringId<T>(id))
}

fun <T> MongoCollection<T>.replaceById(id: String, newObject: T): UpdateResult {
	return this.replaceOne(KMongoUtil.idFilterQuery(StringId<T>(id)), newObject)
}

9.   Let's test it now.

I'm using Postman to send a POST request to
localhost:8080/api/dogs/. Here's its body:

{
	"owner": "John Doe",
    "name": "Good Boy",
    "bornAt": 1583158516
}

Then if you GET localhost:8080/api/dogs/ – you'll see the newly created object.

Now you can add as many resources as you want in a matter of minutes, you don't have to do much for it. You can also use custom paths and define whatever methods you want, Jersey will always handle the parsing and actual servlet creation for you.

It scales as good as any other servlet app, while can also be deployed to other servers like Tomcat. I love server-side Kotlin in comparison to something like Node.js. While it requires a little more initial setup – you can greatly benefit from using it later on. Two of the most important things for us are proper multithreading support and the inherent need to structure the code properly.

I really hope it helps you and saves you some time. If you encounter any issues with this setup – please contact me and I'll update the project accordingly.

It won't be lies if I say that our Mac app, Mate, is the #1 translator app on the Mac App Store, so the last time we made it free was long 3 years ago. However, its iOS counterpart is very far from reigning the translation segment of the iOS App Store. So, we have to find new, unexplored, ways to hit the top charts.

The thing is that the App Store rating heavily affects a whole bunch of metrics: from search rankings to product page view → sales conversion rates. So, it's vital to have it high. Say, if you get 1,000 new 5-star reviews it will most likely catapult your app a dozen positions up the search results. Similarly, if people see that 2,000 other people rated your app with 5 stars, they are more likely to shell out money for it than for an app that's rated with 2.5 and has rants in reviews. It's especially relevant if you heavily rely on organic search rather than word of mouth.

Strategy

Changing pricing in the App Store Connect isn't enough. If you really want a positive outcome, you must do some prep work.

What I did is pitched a few tech guys who often report about app promotions and gave a heads up on Reddit and Twitter. With such support, you'll get a lot of new users in a very protracted period of time, without creating an impression you're a permanently free app (not what you want, again).

BGR posts Apps Gone Free daily. AppAdvice curates one of the biggest Apps Gone Free compilations, updated daily, as well. The golden rule of working with journalists is that there should be a nice story or a milestone. Anything that will help them drive traffic to their sites. People love free stuff, so if a cool, coveted app is on sale, it normally gets a lot of eyeballs.

Reddit is another source of traffic you can turn to when prepping a promo. Subreddits I'd recommend (relevant and traffic-heavy):

• /r/AppHookup (100K+ people). That's what it's for, tracking discounts and promos.
• /r/Apple (1.3M+ people). You're allowed to promote yourself only on Saturdays, on so-called Self-Promo Saturdays, here. We kept that in mind and made Mate free on Saturday.

Reddit's community is often skeptical and sometimes even downright hostile but they have a weakness for good free stuff. Often, you can also get a lot of useful feedback there. If people start leaving comments, actively participate, try to be friendly, open, and steer the discussion in the desired direction. We once had to take our post down from /r/Apple because the discussion went out of our control.

You didn't come for my rattle here, so let's speak numbers. A one-day promotion gave us around 120K downloads. We leveraged them to get a lot of backlinks (good for your SEO), get 700 new ratings (mostly 5 stars), which ramped up our App Store rating to a whopping 4.67 average worldwide, and up to 4.9+ in some of our key markets. If your product is cross-platform like ours, you can also leverage a new audience to upsell (please be ethical, though) your other product. Going free also kickstarted a momentum, so we ended up being #1 free app in some countries. It also affected our sales on a few next days. In a positive way, of course.

Caveats

Don't do it often. Otherwise, people will get used to it and instead of buying your app they'll just wait 'till the next time you make it free. And you don't want that. You want people to happily spend their money on your app, because it's the only way you can build a sustainable business out of it. For example, we did it only twice in the last 2 years. It's very unlikely we'll ever do it again. We've got what we wanted from free promos, an initial growth momentum.

You'll get some 1-star reviews, it's unavoidable. One of the reasons why we still stick to old-school paid apps is that it makes our customers more conscious about purchasing our apps. In other words, only those who really see value in our apps buy them. It helps us avoid bad reviews almost entirely (our apps are rated 4.6+, in many stores even 4.9+). When you make it free, many people who 'just want to check it out' end up being your users, too. My humble observation shows that if a person doesn't pay for something out of their pocket, they tend to value it less. So, if a free user isn't satisfied with something, they'll be more likely to write a furious rant in App Store reviews and remove the app. A paid user will be more likely to drop you a message, more open to communication. At the end of the day, it's in their own interest that you improve what they paid the money for.

Your current users may be confused. Imagine you shelled out 30 bucks on an app and the next day you see it free. Your first reaction is WTF, followed by a bitter feeling of being ripped off shortly after. I think transparency and clear communication is the key here. We didn't hide we were going free for a day. We tried to explain the most transparent way possible that it's a temporary marketing trick and thanked all customers for supporting us one more time. We also gave out our Mac app for free to those who purchased the iOS app shortly before it went on promotion. As a little thank you for loyalty, you know.

Thanks for reading. You can also follow me on Twitter for more thoughts like this. And, buy our apps to support us, a humble yet promising indie developer from Berlin, Germany. By the way, we're hiring.

Unfortunately, it gained the reputation of abandonware in recent years. And there's a reason for that. It was barely updated since 2013. It didn't support promo codes for in-app purchases and subscriptions – the business model for the majority of apps today. Thus, it became too obsolete to be relevant for app developers in 2020.

We at Gikken want to breathe new life into it. We're thrilled to announce that we purchased the app from its previous owner, Denis Hennessy, on December 24, 2019.

Actually, Tokens has a rich ownership history. It was originally developed by Padraig and Oisin from Supertop, then took over by Denis from PeerAssembly, now us. Hopefully, it stops here.

Why Did We Do It?

I was using Tokens for a while. Our support is quite heavy with tickets for which the easiest solution is a promo code (lost Apple IDs, family sharing issues, etc), so the app has always been a remarkable timesaver for me. Every Apple developer knows what a pain using App Store Connect is, right?

When I switched to iPad for some tasks, I instantly felt a shortage of Tokens on iOS. I started spending 5 minutes and wrangling frequent ASC downtimes to generate a promo code again. I emailed Denis asking if he was planning an iOS app. He said he wasn't sure. I casually mentioned it to my co-founder Andrew, to what he replied, 'Why don't we offer him a partnership? We make the app, he helps us market it as Tokens, we split revenue.' It sounded good to me, so I emailed Denis back.

And this was the response:

After a quick pondering, we decided to go for it. Not everyone gets a chance to have a carte blanche on a product they actively use and which saves them at least 10–15 minutes (and even more nerves) every day. Also, we saw an amazing opportunity to ramp up awareness about Gikken, since almost every iOS/macOS developer and reporter has heard about Tokens. And now, we're the company that's going to make it great again!

What's Next?

Of course, we didn't purchase it to shut down or leave unchanged, so we're planning a major makeover – Tokens 2.

Most importantly, Tokens will finally start supporting IAP promo codes! On top of that, we'll refresh the look and make an iOS app to make it possible to generate codes on the go.

I created a Coming Soon page for the update with all sorts of information: https://gikken.co/new-tokens

All current users will be the first in line for a beta which we expect to launch in late March. Tokens 2 will be a new, fully-rethought app. It means the current Tokens app will stay untouched. In other words, if you're using it, you'll be able to keep using it forever.

One of the problems with the old Tokens was its unsustainability. That's also the reason why it was re-sold so many times, and why its previous developers lost interest in supporting it at some point. It was a one-off purchase. Fair enough, there are not so many Apple developers to generate enough ongoing revenue to keep the app frequently updated from getting new users all the time.

Tokens 2 will be subscription-based. Price is yet to be defined, however all current users and beta will get a juicy discount.

If you want to be a beta tester of Tokens 2, please subscribe here: https://gikken.co/new-tokens

To contact us and stay up to date with the development process, you can follow me, Andrew, and @UseTokens on Twitter.

–Alex Chernikov, CEO of Gikken

Nevertheless, we decided to pull third-party login methods from all Mate apps. Starting from February 15, 2020, you will only be able to use your Mate Account in an old-school yet better-working way—with an email and password as your credentials.

We are trying to make the transition as smooth as possible for everyone who used Google or Facebook to create a Mate Account. Most users have already received an email where we kindly ask you to set a password. If you haven't gotten it yet, it's on the way and you'll get it in the next few days.

After you set your password, you'll be able to sign in with your email address. If you don't set a new password by February 15, no problem–your data will stay intact. You can go back to the new account email and set a password at any time.

We apologize for any temporary inconvenience. Trust us—in the long run this decision will benefit both us as devs and you as users greatly.

Why are we doing this?

1. Privacy. In light of recent data scandals that mostly involved Facebook and increasing consciousness of people around the world about what companies do with their data, we don't want to keep Facebook/Google SDKs in our apps anymore. They're proprietary and we're uncomfortable with not knowing what information they're collecting.
2. Maintenance. Sign-in SDKs are frequently updated. Sometimes they just stop working if we fail to update them on time. We want to keep things simple. Our native sign-in will always work.

Note on privacy

We value your privacy. We've never cowardly hidden our Privacy Policy in fine print. On the contrary, we're proud that it's concise, transparent, and written in friendly language. Your Mate Account's credentials are stored in a hashed format, so no one (not even us) can read them.

If you have any questions, check out our Help Center or message us at [email protected].