Boss is requesting that we make our new email web app into a Progressive Web App. We are finding that there is no way to save local files from PWAs but he has asked that we keep looking for a way.
Can somebody please confirm that it is impossible to save files to the local filesystem when the webpage is running as a PWA?
Obviously for an email app you need to be able to download the files from your email, so without access to local filesystem storage there's no chance of downloading files right?
This would need to work across devices (iOS + Android)
Edit: This is not a duplicate of the question: "how to save a file in javascript"
That solution does not work and it seems to be documented that it doesn't work in PWAs on iOS: https://github.com/eligrey/FileSaver.js/issues/479
Anyway you guys have indirectly answered my question, it seems this is not supported and there is no workaround.
The answer is: no, there is no way to download files to the local filesystem in a Progressive Web App on iOS -- they do not support it.
Quote from here: https://github.com/eligrey/FileSaver.js/issues/479
This issue is based on the general iOS WebKit download attribute
issue. The download attribute in iOS is not working, therefore the
browser does not recognize the generated ObjectUrl as download and
ignores the provided filename.
This issue cannot be resolved by WebKit itself, because it involves
iOS proprietary code, which is the reason why all browsers on iOS are
affected. I personally triggered an Apple Care incident assisted by
the Browser Compliance Center of my employer and got a feedback from
Apple.
This incident was classified as high priority and will be fixed for
future releases. It will not be available in iOS version 12.1 or any
prior version.
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.
Is it possible to make an iOS application for enterprise distribution that updates itself transparently? Saying 'updates' I mean completely updating its logic.
A possible usage of this approach is a self-service kiosk (iPad) that is maintained remotelly.
It's not possible to update application binaries directly, but I see some possibilities:
Application that have a single UIWebView and the logic is implemented in HTML5. But we can't use most of hardware specific features that can be used in native applications.
Some multi-platform framework (possibly HTML5-based) that allows to use native application features and that is compiled or interpreted dynamically.
Jailbreak?
What are really working approaches of these?
Consider getting a mobile device management service. Those are pricey.
OR:
First, enable over-the-air distribution. It will take $300/year enterprise agreement with Apple. Set up a website with the app's IPA archive and descriptive PLIST.
Then code a call-home HTTP request on app startup. You may pull/parse the same PLIST that describes the latest version; it has a bundle version in it. Compare that to the version of the currently running bundle.
When a new version is detected, the app shuts down, opens the browser on the download page. In a softer manner, just notifies the user that an upgrade is available.
I've never tried linking directly to the app's download package, but give it a try. In a perfect world, Safari would open up and ask "Do you want do download MyApp?" right away. In a not so perfect world, the user would have to click a link and then agree to download.
I think what you are looking for these days is the "Apple Deployment Program".
You volume purchase iPads which get sent to people, but that you can manage remotely - which also means management including remote updates of applications.
The only thing I'm not sure of is if you can launch an app remotely, so that you could update and re-launch an application.
Here's a guide to enrolling devices for remote management:
https://www.apple.com/business/docs/DEP_Guide.pdf
An old but good summary of the program:
http://www.speirs.org/blog/2014/2/27/understanding-apples-new-deployment-programs
Also watch the WWDC video on Managing Apple Devices for the Enterprise:
https://developer.apple.com/videos/wwdc/2015/?id=301
How could a full version of my iOS app access / copy the database / settings from the free version ?
I'm thinking of providing a free version of my app and I can't see how people then buying the full version could get access to the data from my free version ?
All apps are isolated on iOS. They are installed as different iOS system users. One user do not have permission to access another user's files. In the old times, one common approach to address this problem is to enable iTunes file sharing. And tell users to manually copy the files.
Your better bet is to use the freemium model to sell your app. Make the app free, and unlock extra features via in-app-purchase. This way, your files, documents, settings won't need transferring to the pro version. The app itself becomes pro after unlocking.
Here is the guide from Apple: https://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/StoreKitGuide/Introduction/Introduction.html (though not very intuitive).
The walkthrough here: http://troybrant.net/blog/2010/01/in-app-purchases-a-full-walkthrough/ is very helpful.
Last but not least, be aware that in-app-purchase is crackable. So please read: How to detect "IAP crackers"? , Verifying In App Purchase Receipt from Client , and https://stackoverflow.com/questions/4715414/apple-in-app-purchase-verify-receipt , verify in app purchase , In App Purchase Receipt verification within app .
Note that you are supposed to setup a server to validate iap receipts. Though it's doable from within the app, it's not safe. As far as I can remember, you can test in-app-purchase through StoreKit in iOS simulator v5.0, that should be Xcode 4.2. Before that, it can only be tested on a device.
#Dominik Hadl mentioned you can use a server to sync the file. The operation is usually complicated. If you prefer this idea, you can choose to use custom url scheme to launch one app from another to ease the operation. See steps below:
User press "Begin sync" in the free app to upload the file to your server
Server return the ID of the file to the free app
User press "Launch Pro App and Download my file", which leads to a custom url scheme to launch your Pro version (must be installed first), with the file ID
Pro version use the file ID to download that file directly
I think the only way how you can do this is syncing the data with some server, registering the device and the syncing the data back to the full version.
Because all iOS apps are sandboxed, they can't access any other application data (unless you have jailbroken iOS).
Since multiple apps can share the same iCloud container, I'd say that the best practice nowadays is to "simply" store the data in iCloud.
(I'm putting "simply" under quotes, because it is easy to put data in iCloud and take it out; but if you actually want to do syncing, you may need to do more than just "I'll load from iCloud and save to iCloud" in order to provide the best experience to the user.)
This link shows a video where an app upgrade is "forced" from within the app itself:
http://buzzworks.de/blog/update-ios-beta-apps-from-within-the-app
The App Store is not called in and it's said to work only for AdHoc
apps.
Anyone knows how is this possible?
edit: please give a look to the video before answering. AdHoc apps are signed by the developer and they do not come from the App Store. This sort of forced update is useful when doing beta testing and in enterprise applications.
I've found that it's all explained here:
http://developer.apple.com/iphone/library/featuredarticles/FA_Wireless_Enterprise_App_Distribution/Introduction/Introduction.html
The developer should create an .ipa with the app and a manifest in plist format with the URL to the .ipa and a few other things.
The app can optionally implement its own way to find if an update is available and open
the URL to the manifest.
I didn't it's really possible because the app has to somehow sign itself. The best I can think of right now is that the app is not signed?
You can always force people to go to the app store when a new version is out. Simply make the app connect to a webservice first. Other solutions are not accepted by Apple, or will quite simply not work because of other issues (signing is one of many).
You could also design your app in such a way that forced updates are never a requirement. You can load your user interfaces from the web (Apple has presented some valuable information about that during the previous WWDC), your data can come from the web, and if there is any other correction to do just ensure your app is backwards compatible.
That's how the app store works. And it never requires a 'forced update' ... Well, almost never ;-)
How can I determine if DRM was removed from iPhone application bundle (to protect it from piracy)?
I have an iPhone app which integrates with a third party web service. I use the technique described in this question to find pirates and then have the app "phone home" with the user's device ID and user ID for the web service (I haven't done anything with this information yet, but I was thinking about contacting them and asking them nicely to purchase my app).
In addition, once a user has used my app for a certain amount of usage, I limit functionality and direct the pirates to the App Store for full functionality.
To my knowledge, there's only one way to remove DRM: Crackulous.
So to find out what to look for in a cracked application, I would run Crackulous on your app and compare the app bundles. It should be fairly easy to determine what's been changed by looking at filesizes and running a diff on the files in the bundle.
Once you know what the changes are and to what file(s), just look for those changes in your application to determine if the application has been cracked.
If you find out exactly which files should be checked, please post your findings here so others can benefit from your research.
My previous Stack Overflow question may help you out: Reducing piracy of iPhone applications
Its probably worth pointing out that there are no casual "pirates". Casual users cannot download your app from the app store without buying it. All the DRM-removal schemes require to be run on a legitimately purchased copy.
As to looking at the bundle for changes, as I recall all you need to do is step through the link-loader commands and ensure that the code bundle is still tagged as encrypted. No need to compare it with anything. You'll need to read about Mach-O file format to do this, but thats not difficult, its all documented on developer.apple.com