Please note: although I specifically mention AngularJS, Ionic and Cordova here, I'm really talking about any mobile app (hybrid and native alike) that produces binaries for iOS and Android platforms. As such, I believe that anybody with experience in mobile dev should be able to address the question!
I am building a mobile app for iOS and Android using AngularJS, Ionic and Cordova. My concern is that iOS and Android release updates all the time, some may be buggy or just might be outright breaking changes and all of the sudden become incompatible with the plugin/library versions that I'm using.
This will cause apps to crash spontaneously in production. But it sheds light on an even nastier problem under the hood: making the decision to pin your builds against specific dependency (plugins/libraries/etc.) versions or just always pull in the latest/stable versions of them!
Option 1: Pin your dependency versions
Here we specify the exact version of all dependencies to use. We then fight with the Ionic build to get the app built, but are now good to go. I can expect that if I don't change any of my code, that each subsequent build of the app against the exact same dependency versions will always result with a successful build.
However, when iOS/Android does release a breaking change or bug (or anything that prompts the library/plugin maintainers to go into a frenzy and publish new versions of themselves), because I've pinned my previous build to specific versions of dependencies, I may actually be running on very old dependency versions and it will now be a massive headache to get my app building again against all the latest versions.
Option 2: Use latest/stable versions at all times
If I don't specify dependency versions (and just let the build always use latest and greatest), then I could work fervently to get my app building, then wait a few days (and not change any of my own code) and then try building it again and the compile/build might fail! This is because in between those few days, some project upgraded itself and/or its own dependencies and introduced a build-breaking change.
However, when iOS/Android releases a breaking change that requires me to upgrade to latest dependencies, the headache would likely be considerably less then Option 1 since I'll be on a relatively much newer version of all my dependencies.
Are there any tools/strategies/techniques/etc. that the mobile community leverages to stabilize builds and make it so that I can have more consistent, repeatable builds?
It is recommend to use specific version of your dependencies, you may consider using the notion * at the minor patch level X.Y.* to get the lastest bug fixes.
Your build should be automatic and consistent, there are products that do this for you, e.g BuddyBuild and Buddy support both Android and IOS.
Successful builds is not the whole thing, The app should pass all the functionality and QA tests before a release. So you need to write as much as UnitTests and FunctionalTest to cover the quality checks. There are other QC tools for even further assurance, For example static code analysis tools help you to discover potential bugs and failures, And test coverage tools let you know which parts of your code has not been tested yet.
Here is a Simple CI/CD workflow
Code -> Push -> CI Test -> CD Publish Release
You can set a job to build your project on a weekly basis on the CI server and Publish a Release only if it passes all the Quality Checks
Apps crashing on the new OS versions is not a catastrophic problem, it's common and has its solution, Google and Apple don't release new OS versions to users just like that, Developers are provided with preview builds of the OS and new APIs, Developers usually have more than 2 month to adopt thier apps with the new changes and even use the new API features.
And by the way you have access to crash reporting tools like Fabric.io and Firebase which helps you to discover problems at production.
Cheers
Related
I was trying to run an A/B test using Firebase A/B testing, but just for specific versions of the app. There were no results and no users exposed to the experiment after 5 days of running it.
After that, I tried to run the same A/B test but without a version restrictions and the first results were available the next day.
So I thought that the way I was defining version restrictions was wrong. I tested it in Remote Config, but the Remote Config was returning the correct values when I applied the same version restriction. Here is how I defined the version restriction in both cases:
The app's version names are in the following format X.Y.Z (e.g. 6.51.0, 6.51.1)
Is there something that I am missing? Is the test significantly slower to start if specific versions are being targeted?
This should work. I have tried this many times. Make sure that you're targeting the correct value based on your app configuration. The Version targeting criterion...
For Android app, you should target the "versionName", not the "versionCode".
For iOS app, you should target the "CFBundleShortVersionString", not the "CFBundleVersion".
In addition, you should put the exact number on the console. For example, if the versionName or CFBundleShortVersionString is 1.0.0, then you should put 1.0.0 and not just 1.0.
Can someone please tell me if switching to Beta version of Android Studio, it doesn't make problems in future to publish app or app updates on Google Play?
App updates are related to your code, not the IDE. If you really wanted to, you could even write out the entire app in Notepad/Vim and compile via CLI.
The only difference between Android Studio GA and Beta versions is that Beta versions have tendencially got more bugs and issues. Nothing that should hinder publishing an app to App stores in any way.
Personally, if you are newby, I would stick with Release versions, keep them updated (your dependencies as well) but either way you should be OK.
Hope it helps.
running gradle build on an android project or module yields the following lint report entry:
Potentially insecure random numbers on Android 4.3 and older. Read https://android-developers.blogspot.com/2013/08/some-securerandom-thoughts.html for more info.
This provides an easy to implement patch for said issue. But I'm wondering if it needs to be applied, given that it's 5 years old, or can this be ignored?
Thanks
That depends on whether your app must support Android versions 4.3 and earlier, as well as why you are using SecureRandom in your app (e.g., for information security or secure communications), and the security risk of not using the fix suggested at that page to patch uses of SecureRandom in your app in older versions. Note, however, that according to the Distribution Dashboard, only about 3.5% of Android devices that recently visited the Google Play store ran version 4.3 and earlier. This percentage will likely be less for your app if the minSdkVersion is higher than 10, and this percentage will likely dwindle as time goes by.
I'm developing an android game with cordova 7.1.0 and I would love to know the meaning of the "+" symbol used on the "cordova_project\platforms\android\project.properties" file. So, what would be the difference between this:
cordova.system.library.1=com.google.android.gms:play-services-games:11.0.4
cordova.system.library.2=com.google.android.gms:play-services-plus:11.0.4
cordova.system.library.3=com.google.android.gms:play-services-ads:11.0.4
And this:
cordova.system.library.1=com.google.android.gms:play-services-games:11.0.4+
cordova.system.library.2=com.google.android.gms:play-services-plus:11.0.4+
cordova.system.library.3=com.google.android.gms:play-services-ads:11.0.4+
I really want to understand the use of the "+" symbol because after 1st of November I'll not be able to update older versions of my app because they don't target API 26. I don't want my old versions of the app being unable to login to Google Play Games or to stop showing ads.
Thanks a lot in advance
In Gradle, the "+" is for dynamic version of your dependencies.
Ideally, your builds should be predictable and consistent.
Based from this blog, here are the problems you will encounter if you don't specify your dependency explicitly:
Dependencies can unexpectedly introduce behavior changes to your app.
The same source built on two different machines can differ.
Similarly, builds built on the same machine but at different times can differ.
Past builds cannot be reproduced perfectly. This makes it difficult to revert safely.
There are security implications if a bad actor introduces a malicious version of a dependency.
I am always very excited to work on New Platform/New Release Dependencies Gradle/Android Studio.
But I am more concern about publishing APK to PlayStore as Statble Mode.
We have large number of Android Subcribed Users and
app must be functioning as per expected outcome means app should always work smoothly on Various manfucturing devices/versions/resolution.
Off curse, it must be bug free and it should not crashing.
Please see the attached snap exactly what I doing.
Even I have gone through release note, It is recommending 'Android Studio v2.3.0'
https://developer.android.com/studio/releases/index.html
But I am currently experimenting on 'Android Studio v3.0.0 Beta 6' for learn new functions/libraries.
I am will be very glad and thankful if somebody will help to clear my concern. Thank You.
it is slightly hard understanding, but from what I got you're asking whether or not apps made in AS beta x will work on devices given compatibility and instability in the IDE. (if I'm wrong, leave a comment).
APK's made in beta versions of Android Studio work just as well as if they were made in a stable version. The beta versions are experimental versions, but if you can't sign APK's that can be used no one would use the beta versions. So if you have an APK signed in AS beta x, it can still be used on devices