I am working on Microsoft Intune SDK for iOS. I have below use case:
I am going to release two build one for AppStore and second one is In-House app with same code base and there is no change in app. Now my question can I add some custom flag in Intune Web Portal to differentiate two app say AppStore app is installed on unmanaged device and AppStore build is installed on managed device? Also how can I determine In-House app?
Thanks,
Devesh
Related
I am developing an iOS App that is enrolled to the companies iOS devices via Blackberry UEM.
The app needs to access a client certificate, that is also enrolled via Blackberry UEM.
How can the app access these certificates, because under iOS an app has only access to its own KeyChain.
Do I have to use the Blackberry Dynamics SDK.
The Blackberry Administrator told me, the app is running outside the Dynamics container and I want to avoid linking agains the SDK.
I tried to read the certificates, installed via Blackberry UEM, via SecItemCopyMatching queries, but cannot access them.
Please tell me, if accessing them is possible.
With or without Blackberry Dynamics SDK.
As the title states, I have been developing and testing an app for Iphone. I have got it to install to an iphone via it being plugged into the Mac. But, I would like to get the app place it on my webserver then via a website allow someone to download and install the app. I tried following various tutorials, but as shown below after archiving the app, the export and other buttons are greyed out. Have also made sure 'Generic iOS devices' selected. What could be causing this ?
You have to use Apple TestFlight or use a third party service to allow your beta to be distributed for testing. One good service is HockeyApp, which I am using currently and it is very cheap $10/month.
Without having the UDID of your client, you simply can't!
What is causing this may be that you are not enrolled in the correct Apple developer program.
A stock iOS device will only install an app from a link on a website if the app is signed by certificate from an Enterprise Developer program enrollment (or Ad Hoc provisioned). The Enterprise distribution method is only allowed to employees of the enrolled corporation.
Ad Hoc deployment to devices registered to your enrolled Developer account is also supported by stock iOS devices.
One other possibility is to put a link to your entire Xcode project on your website, with instructions on how anyone with a Mac and Xcode can build your app and then run it on on their device.
We have developed an iOS app that we would like to distribute through Microsoft Intune.
We have already subscribed to the iOS Developer Enterprise program and created an In-House Distribution provisioning profile used to sign our application which is then deployed to Intune.
Using the portal Intune app installed from the Apple app store, our developed app is not displayed in the available app list.
What do we have to do to make our app visible in Intune in order to be installed?
Do we have to install the Distribution certificate somewhere in Intune?
Do we need to use the Intune app wrapping tool?
We already knew that we could view the app through safari, but I thought that, using the In-House Distribution provisioning, we could directly use the Intune App to distribute our production ready app.
We have other "still in development" iOS app that we distribute through Intune using a Development provisioning which we update by hand adding the Test devices.
Anyway, even accessing from Safari, the process of installing the deployed app fails.
I found this on MS Technet. Does it shed any light on your problem?
Currently, end-users cannot install corporate apps from the Microsoft Intune Company Portal app for iOS. This is due to restrictions placed on apps that are published in the iOS App Store (see App Store Review Guidelines, Section 2). Users can access corporate apps (including managed App Store apps and line-of-business app packages) by launching the Company Portal app on their device and tapping the Company Apps tile, which will open Safari browser and redirect them to the Intune Web Portal. For more information about the mobile management capabilities enabled by the Intune Company Portal app, see Mobile Device Management Capabilities in Microsoft Intune.
https://technet.microsoft.com/en-gb/library/dn646972.aspx
I programmed an app for a company and would like to install the app on their iPads without having to submit the app to the App Store since its a commercial app for just this company. Is this possible without connecting each iPad to my MacBook and putting a developer certificate on it.
Is there another way? What about using an URL-link or QR-Code (linking to this url)?
Thanks in advance
Your question is about installing apps without iTunes and the Apple App Store. This is entirely possible and supported by Apple but you are still bound by your developer account's ability to only build signed binaries for 100 devices for testing purposes only.
You can distribute your apps over the air via services like hockeyapp.net and testflightapp.com (free) but these services are just hooking into the iOS system's ability to install signed binaries over the air which has been possible since iOS4. There are several open source projects that provide the bare bones HTML and Javascript/meta tags to install signed binaries over the net - one such one is iOS Beta Builder
If you are creating Enterprise apps for clients (that will exist in production, not just a development environment) then your only legitimate way to provide your clients with apps that won't expire is to use Enterprise Developer Account. The enterprise account has no device limits but the apps you sign with enterprise certs phone home to Apple each time they're launched and are strictly only allowed to be used for a single company and their current employees.
It is because of Apple takes 30% of all the payments, isn't it?
The only way I see is to create usual web-site which runs via browser without installing
TestFlight offers over-the-air beta distribution of iOS apps (on non-jailbroken devices). How can this be done? Is this an iOS feature, or a vulnerability exploit?
This article showed how Apples OTA implementation works and can be used outside enterprises as well: ios wireless app distribution
The complete process is documented by Apple.
Apple also published documentation and sample code for registering devices and get the UDID by using profiles, so your website can detect which device is calling.
Some additional solutions with different strenghts:
iOS Beta Builder, a Mac Application to create the website by using a build. Simply upload the resulting files to your webserver.
Diawi: Simple Web service. Upload your IPA file, optionally set a password and send a link to your testers.
AppSendr: Web service for beta build hosting, similar to Testflight, but does not include the device registration process. But provides deployment utilities to automatically upload new versions.
HockeyKit: Open source project for hosting beta versions on your own PHP5 server with additional functionalities like an client for In-App-Updates, automatic device specific web sites and handling multiple applications. Completely file and directory based.
HockeyApp: Web Service for beta build hosting, In-App-Updates, Statistics, and including device registration, invite and recruitment. Also provides server side crash report collection, symbolication (for all threads) and crash grouping for beta and app store apps (iOS + Mac). SDKs are open source, using HockeyKit, QuincyKit and PLCrashReporter (which is the only safe solution on how to do crash report collection on iOS, see this article.
Note: I am the main developer of HockeyKit and QuincyKit, and one of the developers of HockeyApp.
This was possible before TestFlight rolled out a service. The technique stemmed out of the enterprise distribution mechanism. Since 4.0 devices have supported install from web.
Remember - you still need to sign the beta distribution for a select set of UDIDs you can't just willy nilly install it on any device. All they are doing is taking the email the IPA step out of things.
See:
http://www.alexcurylo.com/blog/2010/08/27/wireless-ad-hoc-distribution/
Update: I want to say that Test Flight is one of the most helpful tools I've used when developing though. Just taking the IPA emailing out of the picture was an understatement- I was just trying to call out the technical mechanism. They do a fantastic job managing the whole beta process. Getting new devices enrolled. Notifying users etc.
Testflight basically uses the normal Ad Hoc as already stated.
For this to work, you need the UDID for every device in order to add it to the Ad Hoc profile, re-compile the app with the new profile an redistribute the new build.
You can get the UDID with the help of the OTA Authentication Request. This is actually a step that is done in MDM before the actual profile is rolled out to the device. It basically asks the device for further information about itself and send it back to a self specified server.
The first step is documented here: Apple OTA Configuration
I guess Testflight uses this right after the registration process to collect the UDID, phone name, ...
Yes this is a core feature of iOS for Enterprise Customers who wish to distribute OTA.
Presumably you would pass your UDID over to TestFlight along with the app and they use their Enterprise Licence to send the app to you. I'm sure I'm missing a lot of the technical details but if you want to know more, Apple has a video on this from WWDC 2010.
Login to developer.apple.com, go to WWDC 2010 Videos and use the link to get to the vidoes. The video you want is "Session 108 - Managing Mobile Devices". It is very informative about what is possible with OTA and the steps you have to take to do OTA provisioning.
Stock iOS devices are "vulnerable" to running the user loading Ad Hoc apps from any developer who has that device's UDID, and registers that UDID among their 100 allowed devices on Apple's developer portal.
OTA distribution is just another way to install an Ad Hoc beta test distribution from an enrolled developer.