Is it possible to implement "Update Available and Install" mechanism for app which is not submitted to App Store.
Thanks.
You should take a look at iVersion which leverages the application bundle identifier to check if a new version of an application has been uploaded to iTunes (using the publicly available iTunes feed).
Because of the bundle id trick you should be just fine, meaning you can safely embed it in the first version you release to the App Store.
As for the non-App Store releases the iVersion provides a simple mechanism of checking for a new version from a plist at given URL. Moreover for beta ad-hoc builds you should take a look at TestFlight which aims at helping people with distribution of their apps outside the AppStore (however for beta builds only).
Related
I have an app created for internal use. I have not published it on the play store, but I have to update it regularly.
Can anyone help...with which library should I use for implementing a self-upgrade system to my app. Any answer would be appreciated.
The answer is - yes,
You can upload your app to the Apple Store and Google Play but Not publish it to the public, instead, you can use internal testing
So only users that you define will be able to see or download your app in the Google Play and Apple Store
Google Play internal test https://support.google.com/googleplay/android-developer/answer/9303479?hl=en
Apple test flight https://developer.apple.com/testflight/
Yep it has some limitations, for example, Apple allows up to 10000 testers but I hope it's ok for your company, but its only way to share app internally without any issues on iOS (android allow you to download apps from anywhere, iOS don't)
The answer is - no, you can't do that - not at least the Flutter* apps. As #Abion47 said, you can publish the new APK and ask users to install it. If you app involves back-end then you can check the (client) mobile app version and display the alert if the version is below minimum version required.
On the iOS side, it is slightly more difficult. For internal use, the organisation needs to sign-up with Apple's enterprise program. You can then distribute the app internally.
*- I've seen certain apps downloads the zip (or whatever) file, and updates themselves without actually going through App update process via AppStore/Playstore. However, it is more of a web part within the particular app which gets updated. The app version as such remains same.
I have an app on the App Store. After the first version, I decided to create a free Lite version of the same app.
I've followed the instructions all over the web to create a multi-target application and I managed to install both version on my iPod.
What is the correct procedure to upload both my apps in the app store? Should I create a new app, named "Myapp Lite", and upload the binary as a completely different apps or maybe is there a way to tell Apple that those two apps are fundamentally the same?
If your lite version is a separate target, it's a separate product in iTunes and you have to do all the same steps as for the regular version.
The only alternative would be to make the lite version the only product and use in-app purchasing to upgrade to the full version.
You will need two create to app, one 'Lite' and one normal one.
yap you should create a new app, named "Myapp Lite", and upload the binary as a completely different apps. If you upload as same app it will be considered as newer version.
I have a 2.0 version of an iPhone app that I want to submit an update for. The first version was built by someone else on their computer. I started from scratch and built a 2.0 version and am ready to submit it as an update. I have access to their iOS provisioning profile and everything but not sure exactly what provisioning stuff I need to download. And do I have to use their old App ID and Bundle ID etC?
If you want to update an existing app in the iOS App store, it needs to have the exact same bundle ID, a higher version number, and be submitted by the same enrolled iOS Developer account to iTunes Connect. You can (revoke if necessary and) create a new Distribution certificate and profiles in the iOS Developer Portal, if you don't have the old ones (and their associated private key), and use those for building the update. The provisioning profile you use needs to be suitable for the app's bundle ID (either a matching or wildcard App ID).
Background:
The current for-sale version of my app uses a wildcard app ID, and the bundle ID is simple and doesn't conform to the com.companyname.appname convention (it's just 'appname'). The App ID it uses is simply of the form 'bundleseed.*', resulting in, I believe, 'bundleseed.appname' when signed with the provisioning profile. (Why? Because this app has been around since the early 2.x days before Apple recommended explicit App IDs, and before XCode introduced the com.companyname convention.)
I'm adding In-App purchase to the app, which requires an Explicit App ID. I've followed the instructions in Technical Q&A QA1680 Updating from a wildcard App ID to an explicit App ID. The result is that I have a new explicit app ID of the form 'newbundleseed.appname', and the new provisioning profile used to sign the app specifies this. The bundle ID in the info.plist remained the same 'appname'.
Problem:
When I deploy the new app from XCode over the top of the old version it appears to work fine. The old-version app instance is replaced with the new app and all of the new features are in place. However, when the app submits a SKProductsRequest it results in an empty list of products. If I deploy the new app as a fresh install (not copying over an old version) then everything works as expected - SKProductsRequest results in a full list of my available products.
I also noticed that the upgraded build carries forward some aspects of the old version, which is strange to me. Specifically, the old version of the app had a default.png which the new app doesn't yet have as part of the build, yet the upgraded app displays the old default.png while it is loading. It's as if the upgraded app is a merge of the old and new.
My primary concern is that In-App purchase will work for my upgrade users. Am I doing something wrong with the Explicit App ID, or is this just an issue with the fact that I'm using the In App Purchase sandbox? In which case, ow can I be confident it will work when released?
Also, any insight on why/how the new app doesn't seemingly replace the old app bundle in-full?
The only thing I can think of is that instead of generating a new bundle seed (as detailed in QA1680), I should have used the old bundle seed when creating the new App ID. i.e. the old App id is 'oldbundleseed.*' and my current new one is 'newbundleseed.appname', and perhaps it should be 'oldbundleseed.appname'. But I cannot do this because the provisioning portal wont let me create an app ID that differs only by bundle seed. If this is my issue, what to do? Contact Apple?
TL/DR: an existing app, updated with a new explicit app ID as to support IAP, works fine except that SKProductRequests result in empty product lists when the app was updgraded vs. a clean install where they result in a populated product list.
How are you doing the upgrade? If you are do a build and run, you will end up with this problem where app is not completely re-written.
Xcode makes some "optimization" decision and copies only files that are really changed and it messes things up.
Create an adhoc distribution and download it to the device that has the older version of the app. Check if that adhoc build enumerates it properly.
Do you implement the request:didFailWithError: delegate method? It is part of the SKRequestDelegate protocol to which the SKProductsRequestDelegate protocol conforms.
I have to agree that StoreKit is not adequately documented. It has been my experience that if iOS sees the same app with different appIDs, it behaves as though they are two different apps rather than overwriting (or partially overwriting) an app with the same title. Still, if your development device is jailbroken: launch the app (in its problematic state), ssh into your device, run launchctl list and see how iOS IDs your app in the resulting list.
I want to know if an app developed with QuickConnect, and uploaded on AppStore will be approved by Apple successfully or will there be any specific terms and conditions for this type of app?
Apple used to have a policy banning apps that were not written on C,Objective-C, or C++. Tha policy has long since changed. So long as your app is completely compiled and does not include any language runtime or interpreters, you should be fine. The reason to be concerned is section 2.8 of the App Store Review Guidelines (Login required), which states:
2.8 Apps that install or launch other executable code will be rejected
That said, it doesn't sound like you'll have a problem.
I'm not familiar with QuickConnect in particular, but other projects that build "native-ish" apps by wrapping web applications in a UIWebView (PhoneGap and Appcelerator being the best known of these) have had no problem getting approved for the App Store. I bet you'll do fine.