I'm developing a game for iOS and I need to make a system to download "packs" after the player bought them with In App Purchases.
I've search on the internet for a method like using a bundle, or just using web services, but I really don't know which one is the best.
Let me be specific: in one pack the player has between 1-3 sprites, 1-2 music files, and 1-3 backgrounds.
So what I need to do is download that "pack" and store it as "purchased". What methods would be the most reusable and modular?
By far the easiest and most simple solution would be to bundle the DLC in to your app with an update and simply use an in app purchase to unlock them for the user. This saves their time and bandwidth as they no longer have to download the files and it saves you paying for a server to host it all.
There are several ways to go about this. In the past I created a system for a previous client that used a manifest that referenced all the files in the "pack", then downloaded each asset. The manifest could be updated to point to updated/different assets if needed, and contained a version number so that the system would know if it needed to update assets after the user had previously downloaded the pack. I probably wouldn't worry so much with a one-size-fits-all approach on this; just get something up and running for this one project that can be used on all DLC packs. Your next project will probably need heavy modifications for the same system to work.
Related
I would like to run code to delete files created on local storage when my flutter app is uninstalled. How can I do the same? Is there any event to handle this? If not, how can I clean up the images generated?I don't see any reference online for this.
If you are saving images to users gallery, that image is no longer the domain of your app, in any way shape or form. If you create a gallery within your app this would be different, also, a gallery within your app would in fact be deleted along with any other memory your app uses. I highly doubt you could access users gallery & delete images even with users permission.
Possible backend server solution: here
This indicates this is not possible as per below:
All of your app's files are deleted by the OS when the user deletes
the app. If Apple wanted developers to have that capability, we would
have that capability 🙂
You could make a case for needing to know the app is deleted if you
are storing stuff on the server side. Currently from the server's
point of view there's no way to know whether the app was deleted or
the user just stopped using it. But locally stored files are not an
issue.
I am also looking for a solution to this & I think server logic will get it done.
Must be some sort of logic possible to discover server side if user is GONE!
I should hook UIResponder of every app, including SpringBoard and any others. In the hooking, I will write something to the specified file. If I set the path to /var/mobile/Library/MyApp, recommended by Cydia, I found that only the SpringBoard and MyApp could write successfully.
So is there a place every app can write and read?
I admit that I'm not 100% sure on this one, but my guess would be no, there is not a path that every app can writes files to on a jailbroken iPhone.
Certainly, jailbreak apps (installed in /Applications/) on a jailbroken phone can write to locations that can be shared between those jailbreak apps. But, as I understand your question, you would like to inject code into normal, App Store apps, so that those apps can also read and write to the shared location. That part I don't think is possible, because jailbreaking does not completely disable the sandbox for 3rd-party apps installed normally, under /var/mobile/Applications/.
Now, there might be a workaround. There are some shared folders that are accessible to all apps for certain purposes. For example, any app can write images to the saved photos album. What you could try is to take the content of the file you want to write, and encode it as fake image data, in a UIImage (e.g. with [UIImage imageWithData:]). You'd probably need to add a valid image header to the data. Then, you save the file to the photos album, using something like
writeImageToSavedPhotosAlbum:orientation:completionBlock:.
Another app could then find the fake photo by enumerating the saved photos album, and then converting the asset back to image representation to pull the real data back out.
However, this seems quite complicated, and possibly wouldn't work (I haven't tried it). Perhaps you could tell us why you want this shared file. Maybe there's a better way to share the data, without using a globally-accessible file?
Notifications can help you with this. Every app will send interprocess notifications about the events. You could start a daemon that will listen for this notifications and save them in a file. Or you could listen for them in SpringBoard as he can write, for example, to /var/mobile/Media. Depends on what you want to do with this file. Check out my answer here How to create a global environment variable that can be accessed by SpringBoard or other applications in the jailbroken iPhone?
I am after some suggestions on how to reduce the final app size that gets submitted to apple?
Or is there any way to have stuff download after the app is isntalled? so that we can keep the app under 20 meg, but then the app downloads the rest of the program after the user has installed it and run the application?
ta
Daz
If your application uses a lot of image resources, your application could download those images instead of building them into the application.
Theoretically possible. Your app can access the file system, so it can make and save, and later read files.
The deal-breaker I see is that for most purposes, Apple probably wouldn't allow it.
They test the program as-is when you submit it, and they'll notice that it just sits there and tries to download a bunch of stuff from your server. If this takes more than, say, 30 seconds, they'll reject it for usability problems.
If the content downloaded could have been bundled with the program, they'll probably have a problem with that. If you could argue that the downloaded content changes rapidly and is a feature of your app, it might fly, but only if you keep it small..
Sure this is totally possible. Since it is most likely some sort of media that is causing a large file size, either images, video, or audio, you could definitely download them after the fact or supply a download button for users to add these features as "extra" content, if they are not critical to the operation of your app.
One thing to consider is that some users are not on an unlimited data plan. So for politeness, they should know what you are doing.
Also, if you are just over the limit, you might also be able to ship the application with the resources in a zip archive and then decompress the archive in the Documents directory.
In many applications images take lion share of the download size, and they can be greatly reduced with ImageAlpha and ImageOptim.
Check out this case study halving download size of Tweetbot by converting images to a more efficient PNG variant.
So, I understand that it's possible to set up in-app purchases for iPhone apps to purchase non-consumables like game levels. I understand the logic behind the purchase part, but what I don't understand is, how can I deliver the new game level.
For example: I build an app that contains the first level and they purchase additional levels. Is it better to build all the other levels into the app and whenever they purchase the app, it unlocks it with a plist entry or something? That doesn't seem very update-able to me. Every time I come up with a new level, I'd have to update the app.
So, what I don't understand then, is what is how do I package up a level and download it as a separate entity that can accessed by the game? Would the level just be some XML with images in a ZIP folder or something? How does the level get added to the game? What are best practices for this type of thing?
I Googled and have found NOTHING about this.
I'm a little bit confused by the concept and any help would be appreciated. I'm not looking for someone to write the game for me, I just need pointed in the right direction so I can develop it on my own.
Your game level is whatever you want it to be; you are the designer, after all.
You should look at NSBundle documentation, which can include property lists, image resources (etc) as well as additional code. Package your bundle (zip is convenient), download asynchronously using NSURLConnection, and install be checking the NSDocuments directory for bundles and load with NSBundle.
Or for a simple game level using existing resources, just download a plist that describes it.
You don't need to have your own server; you can download from me.com if you have a MobileMe account, or any similar service.
I would read over the In-App Purchase Programming Guide. It has all the info you need.
In summary: a user will perform the in-app purchase and get a digital receipt from Apple. Your iPhone application should then contact your server to download the new levels, using the receipt as a verification of purchase.
If you don't have a server available to distribute your levels, you might want to consider a third-party service such as UrbanAirship.
Regarding In App Purchases, I can find a lot of information on all the technicalities of actually making purchases and interacting with the store (how to retrieve product information, verify receipts, etc), but I can't seem to find information on guidelines or special instructions for preparing the actual "apps" or "components," whatever they're to be considered, which will act as the In App Purchases.
For instance, once a component is downloaded into an app, where does it exist in the overall architecture of the app? How do they combine to join forces? How do they know about one another. If I have a game, and using In App Purchases I allow users to both download new levels, but also download new game play modes that can affect any of the built-in or downloaded levels, how do I prepare all of these assets so that they integrate?
I'm not looking for a tutorial, per se, but would love to know if anyone has had experience with In App Purchases or knows of a useful reference besides Apple's In App Purchase programming guide which only speaks to the specifics of making the actual download transaction.
The things you download aren't really "apps", they're just data files like anything else your app can download.
Sometimes, they're not really that, they're just effective "switches", i.e. all of the functionality and data is there in your code already, but it's just protected by a line of code like
if (user has purchased extra levels)
add extra items to menu/list
You aren't allowed to download new executable code; I admit I'm not sure how carefully Apple works to prevent you from downloading scripts that control your program's behavior, since it would be very difficult for them to tell what is intrinsic to your original app or not.
In my own programs, I've put the control logic and tables into the main application, and separated out big resource files into a separate ZIP file. When the user buys the add-on pack, they do download that ZIP file of images which keeps the original application size down, and the program just uses those images out of the documents directory instead of the application bundle like it would if they were built in.
I am using the Urban Airship in-app purchase support, which insulates you from running your own server or learning most details of the StoreKit, at the cost of a slice of your revenue.
You can let the levels be in the app from the beginning and just let them become available when the user pays an in-app level. This is by far the most simple solution.
If you want to have downloadable levels you will need to set up an own server that will deliver and check correct purchase transactions with apples servers. You will also need to create all the download and architecture to load and use these levels into your app.
But, you can have a look here http://urbanairship.com/in-app-purchase/ for help in creating downloadable items.
This code will get you going: works on the simulator too: https://github.com/boxerab/InAppPurchase