iOS determining how to open file - ios

I'm developing an app where people can download files, and have no problem downloading and saving them. The problem is, when some files are downloaded, they have no file extension (http://test.com/test, instead of http://test.com/test.zip), and I can't determine what kind of file they are. I've tried using NSHTTPURLResponse's suggestedFilename property, but that still doesn't put an extension on the file. So my question is, how do I know what kind of file something is without an extension? I've also tried getting the mime type of the file, but that didn't work.

Related

Working with custom user files

I'm currently studying swift and came up with such a question:
What are best practices to work with custom user files like .pdf, .doc?
For instance, I have application, that loads different files from server like .pdf, .ppt, .zip and so on, how to present them inside my app?
While googling I came up with solutions mainly for images, but nothing particular for other file types.
For now, what I have is - downloading files from server using Alamofire and saving them to documents directory.
Could anyone please recommend how to present this files inside my app after I saved them?
Possible solution that comes to my mind is web view, but what about zip? Is there some kind of universal solution? I know that there is Files App in iOS 11, but what about iOS 10?
Many thanks for your attention!

iOS file upload - original filename

I have a simple HTML file upload snippet that works under iOS as well. However my problem is that the filename of the uploaded file will always be 'image.jpeg'. Is there a way to get the original filename - i.e. 'IMG_0001.jpg' instead? The major issue is that if I have 2 files selected they both have the name of 'image.jpeg' as opposed to their unique names.
Safari on iOS will always make the name of the uploaded file image.jpeg, presumably for security/privacy purposes. You need to generate your own name for the files, which is a good idea in general for uploaded files: you never want to trust the client too much.
If you are targeting more than just Safari on iOS, you will still need to handle this case because it is reasonable that people might upload multiple files with the same name, but originally located in different directories.

How to restrict ios sandbox access from .app file (Migrating an App to a Sandbox)

I am able to see the source code from my .app file that is i am able access image
files. How can i restrict that? I dont want my user to access the files from app. Please help me in resolving this issue.
Update: Sorry i was supposed to write .h/.m files are not accessed but image files can..
There is a mismatch in type , i didn't observe
You cannot see code from the IPA you upload to the store. No one can see your code. Someone could, however, see you image files, audio files, sqlite files, plist files, etc.
Per your update:
You cannot prevent the files from being accessed. It's like the web: if you can see it, you can steal it.

Protect Images inside my app from copying

I have an app that uses copyrighted images that I have permission to use. If a user downloads my app onto their computer using iTunes, they can basically unzip the app file (change filename to add .zip, unzip then show package contents), and see the images.
Is there a way to prevent this? Or am I wrong about this?
To the best of my knowledge there is no way to stop this method of accessing the images; the only alternative I can think of is to encrypt the images and store the encrypted files in the app. Then decrypt the images at runtime.
This won't stop the most determined adversary but would stop people accessing the images without some effort on their part.
A determined adversary will likely be able to get at any files used by an app on a device in their possession.
To defeat a lazy adversary, you might only have to change the file names into something they won't recognize as an image file. Or change a few bytes containing the file type signature at the beginning of each file, rendering the file corrupt. Your app can copy them into a temp file and fix the signatures to display.
Apple reportedly encrypts an App store distributed app's compiled C code. So another possibility might be to embed (portions of) the copyrighted images as hex data inside your source code.

Custom file types with iOS Document Interaction Programming

I understand the basic of Document Interaction Programming and UIDocumentInteractionController and I've got it working in my app. However I'm having trouble with specific details of using custom file types. I can't find this addressed in the Apple docs anywhere.
My app uses it's own file types with unique extensions. The files themselves are just plists (xml), but I want the device to treat the files as only openable in my app. Originally I implemented the Document Interaction stuff to treat them as XML while I got it working, but now I want it to treat them as binary files that it needs to hand off to my app.
At the moment, if you have one of my files in an email attachment, iOS first shows the QuickLook (which just spews all the text content of the xml out) before you can choose to Open In. Similarly if one of my files is opened with Safari, Safari just shows the XML and doesn't give you the option to show it in my app at all.
So how do I get iOS to not treat my files as XML? I've changed the "Conforms to UTI" value and "public.mime-type" value in the info.plist, but it seems to have no effect.
Any tips greatly appreciated.
As far as i understand the UIT concept of Apple you cannot just change the file extension to change a potential UIT of the file. If the file contains XML-Data, other apps as well as internal apps might recognize your content and show it internally as XML.
Try to store your Plists with NSPropertyListSerialization NSPropertyListBinaryFormat_v1_0 (then you readble XML)
When you did that without success, why not trying this:
use zlib to compress the XML plists afterwards to a zipped file.
make a "unique" file extensions (<file>.myappname)
this should "hide" other apps and quick view.
Tell me if one of the ways did work for you.

Resources