Please confirm:
Bitcode is an intermediate representation of a compiled program. Apps you upload to iTunes Connect that contain bitcode will be compiled and linked on the App Store.
From Bitcode (iOS, watchOS).
It is App Store who compiles and links the apps, so how about enterprise app?
I like this iOS9 feature as user could download the required slices to device for updating app quickly with least file size. Bitcode is enabled by default in Xcode 7, but for enterprise app, we upload the app updates to our enterprise server and our client users download it from our server via links. No app store is in this process.
Is that OK for enterprise app with Bitcode enabled? If so, who will own the compile & link duty?
It is absolutely fine if your app contains bitcode even if you do not distribute it over the AppStore, however the app becomes bigger - it contains slices with object code and bitcode for each CPU architecture (more details on this topic can be found here: Bitcode Demystified).
I'd recommend to disable bitcode since there is no AppStore phase in your distribution model and nobody can take care of it.
If you still want to achieve this goal (smaller app size), then you can emulate App Thinning on your own: build a few versions of your app - one for each CPU architecture, upload to your server and put some smart service in front of the server, which will check user's device (via User-Agent) and redirect to a correct binary.
I didn't try this option, but it should work, the only extra-thing you need - table/mapping between device version and CPU.
Related
Currently,
My team and I are developping an Android Auto enabled app. And it appears to me this app is only available in my car unit, when I enable unknown sources in the Android Auto app.
However I'm wondering what defines an unknown source and how do I make sure my app is not an unknown source. Does Android Auto communicate with the Google Play Services for this or do i need to sign the APK with specific data?
How are you deploying your app? If you are deploying with Android Studio: as I recall you won't see it on your real automotive head unit, just the emulator. To show on the head unit it needs to be deployed in the Play Store, at least in developer and pre-release mode while under development.
First of all: Android Auto runs on your own device, meaning it adapts the same permissions you granted to particular apps. If your app doesn't have an app in the normal UI or you didn't open it on your phone once, then it would usually prompt you to grant permissions the first time you open it.
An unknown source is pretty much any way of getting your app outside of the Google Play Store (and OEM-specific app stores like Samsung App Store for Samsung devices etc.).
That is especially common if you e.g. download an .apk from the internet and want to install it, but your phone thinks their own file manager is an unknown source (because it is not intended to download apps).
I am new to macOS app development. I have knowledge on Windows App development. I have a server application which can be installed offline. For communicating there is a client library which is a .dylib. I want to distribute the .dylib using macOS App Store so that third party application can consume the library.
How to install the .dylib and headers to a location from macOS App Store as a installer?
You cannot distribute dynamic libraries and header files through the App Store. It's for applications only.
Instead, have a look at other means of distributing libraries such as CocoaPods, XCFrameworks etc.
Mac App Store is quite restrictive when it comes to installers. Usually you would distribute an .app that can be run directly and the app then installs more things if needed.
What kind of apps would consume your library? Why not provide a "Framework Bundle"?
This is the typical way to distribute libraries within macOS
How to install the .dylib and headers to a location from macOS App Store as a installer?
You don't. I'm afraid the App Store is not a package manager.
While you can put libraries, CLI binaries and other resources inside a GUI app bundle, you cannot distribute anything other than a GUI app bundle via the App Store. And neither could 3rd parties mark their app as "depending" on your app. And if they linked against a dylib outside of their app path, then it's highly likely that the app would get rejected in review because it would be found to not work. Again, it's not a package manager.
All apps on the App Store are required to be self-contained, so the way Apple wants developers to handle dependencies is by bundling a separate copy.
Thus, the only "supported" way to distribute your library in a way that can be used on the App Store is to make it available for download on your website, and then have each developer bundle a copy of it when they ship their app.
Of course you could opt for other (or additional) channels like brew, which are actual package managers, but that won't help with anything on the App Store.
i have generated the .ipa file and trying to add in any iphone device but its not adding.
the error is showing like:- couldnot install(in xcode).
i tried with apple configurator 2:- in this scenario app is installing a bit just assume
75% and after that the app icon is getting grayed out and clicking on that app is giving
popup as :- could not install please try later.
somewhere i saw that you have to allow from your device to trust this app, location is like :- settings > general > profile&management > you will find your profile here for new app installing.i didn't get any profile there.
FYI
i am using free developer account and created the xamarin app from windows and building it through mac, the xcode version is 9.4 beta and i also tried to override with xcode version 11.3.
i am not getting whether i am missing something or messed up with xcode versioning.
i am using free developer account and created the xamarin app from windows and building it through mac...
If using a free apple developer account , you can not install a .ipa file to iOS Device .This is limited by Apple.
About IPA Support in Xamarin.iOS , you will see there are two uses as follow :
Ad Hoc Testing — An iOS application can be deployed to up to 100 users (identified by specific iOS device UUIDs) for Alpha and Beta testing purposes. See our Provisioning an iOS Device for Development documentation for detailed information on adding test iOS devices to your Apple developer account, and the Ad-Hoc guide, for more information on how to distribute in this way.
In House / Enterprise Deployment — An iOS application can be deployed internally, within a company, which requires membership of Apple's Developer Enterprise program. More information on In House Distribution is detailed in the In House Distribution guide.
In either case, an IPA package (a special type of zip file) must be created and digitally signed with the correct Distribution Provisioning Profile.
If using a free provisioning , there is a Limitation as follow :
Access to iTunes Connect is limited and therefore services such as publishing to the App Store and TestFlight are unavailable to developers provisioning their applications freely. An Apple Developer Account (Enterprise or Personal) is required to distribute via Ad Hoc and In-House means.
Therefore , if need to add .ipa file in iphone device , you should use a paid Apple Developer Program account.
At our company the process we execute normally is:
fix/implement
test ad-hoc version
create AppStore package
test that AppStore package by installing it directly through iTunes.
submit version to AppStore.
The reason why we need to test also the AppStore version is because some payment services wouldn't work if we didn't. So we need a real environment.
Previously to the inclusion of the iOS App Extension (sharing) we could do this process without issues, but now after doing the same process we can't do it anymore.
We can;
test the ad-hoc version by signing the app extension as ad-hoc.
create and submit the app store package.
However we can't install the app store version anymore, the error mentions that there are issues with the signature, more precisely:
(Entitlements found that are not permitted by provisioning profile)
Does anyone have any idea why this could be happening?.
You really shouldn't be able to install the app store version on a physical device and run it.
It can work in certain scenarios (like if you had previously installed development builds on there and there was a valid development build on the device when you try to run the app store build). Maybe the device has the old app provisioning profile (which would not have the app extensions entitlement). The new one that is embedded with the app (and has the appropriate entitlements) is an App Store provisioning profile and is not valid for running directly on the device.
I would make a new build config in your project that is a copy of the Release config, except for only the code signing settings. That would allow you to run a build that will be exactly the production App Store build, except for the code signing settings.
I am using Phonegap Build to quickly deploy and test my applications. For this to work, I had to go through an elaborated tutorial on creating provision files and certificates and borrow a Mac to make use of Keychain. By then however, I only registered one device UDID.
Now I want to add more devices, but I dont want to go through the whole process again, also what if I have to add other devices later?
So I was thinking to use Testflight, which only requires that you upload an .ipa file (apart from having a developers account etc). With Phonegap Build you can easily create these .ipa files.
However, since I am working with Windows, I dont see how I can upload the .ipa files on Testflight. Most tutorials online talk about using Xcode and some other Mac program.
Is there any way to upload it anyway?
Hacks might be available but since Apple integrated TestFlight into iTunes Connect - which (at this time) does not have a public API - the only official solution is to use Xcode or Application Launcher for ipa uploads. Both are only available for OS X.
An alternative solution might be to use an iOS CI/CD (continuous integration and delivery) service to do the upload. We happen to have one - bitrise.io, CTO here - but you can find a couple of other services as well.