I have an iOS app that communicates with a web service, this product will be licensed to customers for their employees. Each customer will have to install the web service on their own server and provide an IP/URL for the iOS app to communicate with. Right now, the web service URL is coded in the app. I won't know the customer's web service URL before giving them the compiled app.
I don't know enough about enterprise distribution to know how to do this. Do if I need to compile the app for each new customer with their specific web service URL, then give them the app? Or is there is another way this should be done? I was thinking a plist file or manifest that can be configured with the URL but I'm not sure. How do they update that and get the app to use that? I had a developer make this app for me and they said the URLs shouldn't be in manifest/plist files.
I can't find any information about this on the apple developer site or on this site.
You can just add text field in your app settings or at the start where user can define its server URL like www.abc.com For all your customer rest of your path (webservices/yuorservice or what ever you use)will be same . Then you get this url and save in your user defaults to use it for the future for that user.
Using this approach you only need to compile app one time for all the customers.
App has no knowledge of manifest file
Your developer is right--you should not include any app-configuration information in the manifest file, since the app has no knowledge of the manifest file or web page that it was downloaded from. Here is a link to an answer I gave regarding this topic.
Enterprise deployment rules
Apple only allows enterprise deployment internally within a company. So, distributing an App through your enterprise license to multiple companies is prohibited.
Approach
I can think of one option that might work for you, given that you have a URL that should change for different customers.
This assumes that you will employ a login.
Devices
Your login web service response to the device can include the URL that is configured for that customer. This URL can be one piece of data inside a configuration file in JSON format.
Web Server Admin Page
You can optionally employ an Admin page, also accessible through login, where your customer can set the URL, and any other settings. The advantage of including an admin page for your customers is that they are able to manage the product on their own, without the need for additional product support.
Related
At work we have developed an individual customer specific software application that is in use for a long time. We have a new requirement in this same program to implement an option for sending emails directly from the program.
The user is able to add his own email account with the credentials and login through our program. For Microsoft and Gmail accounts OAUTH is implemented and something here is not very clear.
For Gmail-API we have made an OAUTH Client and Consent screen on Google Cloud Console which we need to publish and verify and here is where the problems start. I am not very clear with the whole process of verifying the app.
In the steps for verifying is stated that we should verify a domain for the app, but this software is not hosted anywhere on internet and is not publicly available, it is available to a number of specific users (2000-3000).
Also Google requires a YouTube video of the software to be available publicly, which we are not able to upload because of customer requirements. Also here is required a Data Protection Policy page for the application which we as a developers don't have because we are only developing the software.
Other thing that is not clear to me, how is this type of software rated by Google, internal or public?
Have anyone experience with this or something similar?
Verifying an app for one of the Gmail scopes is a very complicated process. This process depends upon which scope of authorization you are requesting of the users.
In your case you are trying to send an email so you are using the users.messages.send method from the Gmail api. This uses a restricted scope. Which means you will need to go though the full process.
First of it doesn't matter if your application is hosted or not. It also doesn't matter that you give this app to a limited number of users. What matters is the scopes you are using.
You will need to ensure that your domain has been registered via google search console. So this app will need a domain
Once that is done you will be able to host your website, and the privacy policy on that domain.
You will need to create a YouTube video showing your application running, and how authorization is used.
You will also need to submit to a third party security checkup of your application which is not free and will need to be done once a year.
All of this is needed because of your consent screen it doesn't matter if its hosted any where, It also doesn't matter if this is only available to specific number of users.
If all of the users are part of a single google workspace account, that has created your client id and client secrete then you can set the app to internal and you wont need to be verified. This only works for google workspace domain accounts.
I have an app on store and all client are used it. Sometimes some client needs additional feature that isn't wanted by others so in that case I make AdHoc build for that particular client, but it is not proper solution.
I think on Enterprise solution but apple not allowed to distribute outside the organization in it and I have all users are clients.
If your app has a user login, download a user specific configfile directly after login and check in code for feature availability by looking into it. Large companies like Spotify and also startups do it this way to test new features without releasing them to all.
i am developing an app for the app store but it seems i am required to have a support url. I do not have a website dedicated to my app and do not want to make one. Can i use a twitter account dedicated to my app as a support url?
To quote the documentation:
The support website you plan to provide for users who have questions regarding the app. The support URL must lead to actual contact information so that your users can contact you regarding app issues, general feedback, and feature enhancement requests. The URL can specify a localized site.
Include the entire URL, including the protocol. For example, http://support.example.com .
Make sure whatever page you link to contains that specific contact information. A good example of this would be a page with an email form or other way to directly contact you.
I'm trying hard to get my mind wrapped around how you would be able to store files in the cloud from an enterprise app without requesting the user to log in.
The background:
I'm developing an iOS app that will be distributed to certain employees in our company. As of today we already have an app that uses an FTP server to upload user created files. In this new app, I would like to skip the FTP server and instead use some sort of cloud storage (DropBox, Google Drive etc.)
The users will upload some files (around 1-2 uploads per day) to the cloud service, and people at our HQ will be able to look at these files.
I don't want to have each employee create a personal cloud drive account that would be linked with a "master" account. Rather, I want this specific application to always upload it's files to the cloud storage "master" account. Is this even possible?
Since only our employees have access to the app, I don't see the security factor as limiting. The information sent is not of use to anyone else than our company (no high-security stuff).
Is it possible to "hard-code" an OAuth token that corresponds with a certain account that the app always uses? Are there other possibilities that I'm not aware of (other than FTP or cloud storage)?
Any help will be appreciated.
Regards,
Jens Nilsson
how about use one dropbox account and hard code it in your app? then your enterprise user can upload their files respectively. surely you need do some trick to make no any file with duplicate name.
i am developing one iOs application that uses a parse cloud service to upload user generated files.
in that parse service, user dont need to create a account separately.each and every user can be able to uploads files to cloud where user can be able to visit all the files which is in the cloud which is created by some other user.
suppose if we want limit some user files accessibility or upload files privilege also we can achieve that through using the parse.
i just remember parse is not open source.
We have an enterprise distribution of an app that we would like to distribute only within our organisation.
We've built the ipa file and the plist which points to the right places, and created the html page with the url: itms-services://?action=download&url={link to our plist}.
Our problem however is securing the distribution process. We want our employees with company owned iPads to be able to download the app while on the move (they're highly mobile). So we want to place the plist and the app on a public website which requires login via an oauth service.
Our problem is that if we require authentication on the URLs for the app and the plist, the itms-services:// url no longer works. What happens is that the user clicks the itms-services link, and we see an un-authenticated request for the plist (which is redirected to login) followed by a "Cannot connect to {hostname}" on the device.
At the moment, the only way I can see this working is if the ipa and the plist files are not checked for authentication. This means (I believe) that someone guessing our URLs to our plist file could create their own itms-services link and download the app without authorisation and effectively cause us to violate our agreement with Apple to only distribute to our employees.
My question therefore is - how can I create an itms-services link that does not expose the ipa and plist files to the public? If it's relevant, the website is built using nodejs and the app is a PhoneGap app.
I've figured out a solution to this.
We can't use the oauth authentication because the iOS install process doesn't present the opportunity to enter credentials.
Instead, when the user requests the page which we display the itms-services:// link on, we create a unique string to that user and encrypt it using AES-256, then store it in the database.
Our URL then becomes: itms-services://{url to plist}/{encryptedString}. We tried using a query string, but it appears the iOS install tool doesn't pass that on.
When the install tool requests the Plist, we verify the encrypted string against the database, open the plist and rewrite the url to the ipa file to {url to ipa}/{encryptedString}.
This seems to work quite well. The only issue I can think of at the moment is that the URL could be shared publicly be a legitimate user with someone who shouldn't have access. I think we could get around this by ensuring the url is time sensitive (e.g. only available for 5 minutes).
Finally, any requests to the plist or the ipa without a correct encrypted string get rejected.
I hope that's useful for someone!