Manage free version and paid version in Flutter - flutter

What is the best way to manage free version and paid version using Flutter?
What I have checked
One dirty way is having two almost identical projects, and building one as a free version and the other as a paid version.
Another way is implementing differences between versions as features after in-app purchase. (I might go with this if there is no better way.)
I found info for Android and for iOS (which are the ones written above), but does Flutter provide a better way?
Environment
1.12.13+hotfix.9
Dart 2.7.2

Two ways to do this:
Implement in-app-purchases with a non-consumable (if you want to
unlock premium features 'forever')
Create a subscription that a user
purchases to unlock premium features (potentially combined with
a free trial period) for a period of time
Anything else is likely to get blocked by the App Store and Play Store review process.

Related

Which one is good RevenueCat or in_app_purchase library for Flutter In app purchases?

I have an application published in the Appstore and Google Play Store. Which one should I use for this?
Well, while the in_app_purchase package is the official package from flutter, you have to write a complete backend that communicates with the Google Play server and the Apple Appstore server to verify your subscriptions and consumables/non-consumables what is really important to protect your app from fraud.
However RevenueCat's servers handle that validation process for you.
I personally always prefer using official packages, but if your app is generating lower revenue/has not so much users/... its probably worth it to use RevenueCat's Plugin in the beginning as you save a lot of time and it is free to use up to a monthly revenue of 10,000$
Later if your app is generating higher revenue you can consider writing your own backend.

How to implement In-App Purchases Subscription in Flutter?

I want to provide auto renewable subscription in my Flutter App for both iOS and Android devices. Users can subscribe for 1 Month.
There is not an officially maintained in-app purchase plugin yet. But there are lots of plugins about In-App Purchases in Flutter.
Which one is the best? How to implement? Are these secure?
==== UPDATE from 11.03.2020
Hi, I can see this post still reading by people who looking for a
method of how to work with subscription in Flutter. During 2019 I made
two apps with thousands install where users can buy a renewable
subscription on the 2 platforms. Until February 2020 I used for this
package from Flutter team https://pub.dev/packages/in_app_purchase,
BUT - there is no way to get info about the user to unsubscribe in
iOS. This is not the plugin issue, but the iOS approach for the
process. We should implement our own backend for security reasons (by
the way Google also recommends to do the same, but still left the way
to check the state directly from the app).
So, after some researches, I found guys who made backend and plugin
and it is free until you have less than 10 000 USD revenue for the
month. https://www.revenuecat.com/
https://pub.dev/packages/purchases_flutter
I've implemented this plugin in my apps and it works like a charm.
There is some good approaches that allow you to get a subscription
state at any point in the app. I'm going to make an example and
article, but not sure about the timing.
==== UPDATE from 03.10.2019
I recommend using new package from Flutter
team https://pub.dev/packages/in_app_purchase
The example with code is here https://github.com/flutter/plugins/tree/master/packages/in_app_purchase/in_app_purchase/example
With this plugin I successfully implemented payments and recursive
subscriptions to Android and iOS simultaneously. With the old package I
had some minor issues.
You can use nice plugin flutter_inapp_purchase
I've used it for the app that I developed and it works well. You can use my example of how to work with subscription - github
There is a complete working example - when you run it, you should get the screen
(do not forget to log in to Google play in an emulator or you will get “in-app billing version 3 NOT supported”)
For those looking for resource on how to implement IAP, Flutter team wrote a tutorial using in_app_purchase package and Firebase as backend for validation.
Link: https://codelabs.developers.google.com/codelabs/flutter-in-app-purchases#0
Android and IOS both with In-App-Purchase with auto-renew working best and easy way in Revenuecat plugin Link https://docs.flutterflow.io/advanced-functionality/payments/revenuecat

can public game for Android use Unity Personal

I'm just starting to work with Unity engine and I want to know
1. Unity free version has the ability to publishing game on Google Play Store?
What are the limitations of the free version (Unity Personal)?
Thanks.
The public, free version has virtually all the functionality that the paid version has.
To answer your questions:
Yes, unity free can publish on google play
The limitations are mainly on Support from the Unity Company. Also you get a discount in the assetstore with the paid versions.
You need a paid version if you earn more than $100.000 a year.
I believe there may be an extended profiler with the paid version, but I'm not sure.
Also, the free version forces the Unity logo on your splash screen (initial loading screen) on publish builds. You can remove this by purchasing the paid version.

Android App Bundle - Is it possible to have a pricing policy by features

About the new app publishing format (App Bundle), it is said that:
With Dynamic Delivery, users can download and install dynamic features when they’re needed.
But is it possible to set a price to one of those dynamic features and so not allowing everyone to download it? I do not see anything about pricing policy in the official documentation.
Thanks.
Dynamic modules and in-app purchases are two distinct features that can be combined together, yes.
You can guard the code that downloads the feature (and also the one that executes it) behind the purchase of an in-app product.

Beginning Phone Applications Development

I've been developing applications for a long time now, but now I want to jump into Phone applications development. There are four main candidates:
Nokia's Symbian
Apple's iPhone
Google's Android
Microsoft Windows Mobile Phone
Can anyone suggest one, considering documentation, market, samples and availabilty of emulators, I'm not a millionaire so I can't buy it unless I know it would mean profits!
I don't have much preferences as for languages, but to stay within C# would be nice, however I've been thru Assembler for a long time, so it's hard to scare me :)
There are many factors to consider such as where the biggest market is, and so on. But ignoring those factors and thinking just about technical and money issues, the clear answer is start with Android.
The Android SDK is totally free. The iPhone dev tools need a Mac, so if you're not a Mac user, you need to buy a Mac. If you're not a Mac user, then it's probably a safe bet that you don't already know Objective C, which you'll need for iPhone. You don't even need a phone, there is an emulator that works wonderfully. It's very rare that I've made something that works in the emulator but doesn't work or works differently on a real phone. So the emulator is quite excellent.
Android programming is Java, and is very similar to C#.
Android development is much more approachable and easy for development (for getting started at least) than Objective C and iPhone.
There are many online resources available, but the book "Hello, Android" is actually very good. It's dated, though, goes back to version 1.5 of the SDK and we're at 2.2 today, but the fundamentals for getting started are pretty much the same.
You may decide to go another way, but in a handful of hours you can be writing your first Hello World program on Android free of charge. Even if you decide to start on another platform, you can hardly go wrong by giving Android a shot first.
Another thing that's worth noting is that Android is way easier to sell and distribute your apps than iPhone, making it a better place to start. There is no app approval process with the Android marketplace, so you can have your app posted for sure without wondering whether the powers that be will approve your first app for sale or to give away.
It bears mentioning that if you go the Microsoft route, your C# experience will transfer almost completely, and you'll be amazed at how close the compact SDK is to writing plain Windows apps. (At least, it was in 2007, the last time I wrote a Microsoft phone app.) But forget I brought this up-- if you want to be a serious phone developer for consumers, I recommend you forget about Microsoft at least for now.
If your plan is to create and market Paid apps, versus just free ones, don't forget to also consider and evaluate potential revenues and existing competition, instead of just your development cost of entry.
My local, and not necessarily statistically significant, sample shows a larger number of iPhone developers making more money than Android developers. The amount of money to be made, if you produce an app just near the top 10% of apps in many categories, may be well over enough to amortize the higher initial costs of a development system, certificates and testing with iOS devices.
However, for iPhone development, you may have to create a stand-out app, as many app niches in the App store are already filled with several dozens of apps. The absolute number of potential competing apps in the Android store is far lower in many areas. You will need to evaluate the competition in your area of expertise or interest.
First, you forgot RIM (Blackberry's OS). You will find this graph usefull to analyzie your audience (I think the graph is for the USA only): Source of the image
Microsoft Phone 7 will soon reach the market with new devices so it is hard to tell what market share they will take. Their IDE for Windows Phone 7 is free and it supports C#.
Can't say much about the other OSs other than the fact that iOS has the most extensive store and fanatic fans that are willing to buy those apps- but that info is only from what I read on the net and see from friends around me.
You may find the beginning-phone-applications-development question helpful as well.
Windows Phone 7's API will be based on C#, but most of the other stuff about it is still speculation.
Android has the lowest cost of entry, essentially free - and will use Java (which is very similar to C#).
The iPhone has a higher cost of entry - you need to own a Mac (or somewhat less legally, a hacked together OSX install). Plus once you've devloped your app it costs $99 per year to become a registered developer, allowing you to put the app on actual phones, and sell through the App Store. You'll also need to learn Objective-C, which uses a syntax which is a little different to C# and Java.
On the flip side to this, the iPhone tools are very good, and the market is huge, there are also some good online free courses (including the videos of the Stanford course available on iTunes).
Don't know much about the Nokia toolset, and I wouldn't start developing for old-school Windows Mobile now - it's a dead-end.
Some thoughts:
If you have a mac then the choice is certainly the iPhone since all the development tools are free.
AFAIK the Android SDK is an Eclipse extension and can run on pretty much any environment, and is also free.
Mirosoft charges for its IDE, and probably has the smallest audience.
I am pretty sure you will find more community support for iPhone or Android development too.
There are also cross platform options, such as PhoneGap, which may be worth your consideration.
With all technical considerations being roughly equivelant, the most "profitable" platform would have to be the one with the largest untapped consumer base for the particular app(s) you intend to develop.
Two factors come into play which you can assess
Size and growth potential of the market. There are plenty of charts and opinion articles around on this to allow you to make an assessment. If you can't find them, just drop those 4 topics you listed into google alerts and watch the incoming articles to your mailbox for a while.
Saturation of the app marketplace, in particular in the markets your app addresses. Your own market research would be best at identifying this.
The only other consideration which may apply to specific types of apps would be if there is a fundamental feature your app requires of the platform, and whether respective platforms support it. For example you won't get far making a flash based player on iPhone.