I've added UIFileSharingEnabled to the .plist. Per suggestions, I have:
removed the app and redeployed it several times
attempted to disconnect after redeploying
I have not been able to get the app visible in the File Sharing section in iTunes. On another app, this works flawlessly. The app where it doesn't work has a bit exotic internals (an easily portable game; as such, it has its own mainloop, it doesn't have a main nib, ...). The app where it does work is pretty much standard deal. Also, testing was done on two different devices: it worked on iPod Touch 4 with iOS 4.2.1, but it didn't work on iPhone 3GS with iOS 4.2.1.
Since it's a bit difficult to isolate the problem (and I could probably spend several MORE hours isolating it), is there any other known requirement to get file sharing to work?
CFBundleDisplayName is additionally required in the .plist. Why Apple elected to require this, I have no idea.
Related
For development reasons, I started developing a universal iOS app, but want to launch with the iPhone version only first.
Besides modifying the “Targeted Device Family” to “iPhone” in the build settings, are there any more necessary steps to prevent users opening the already developed iPad classes/views on their iPad?
Moreover, is there a possibility for users (e.g. with jailbroken devices) to enter the app in iPad mode on their iPad? (How) Can this be prevented?
You can put a condition like :
if (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPhone){
--- do something--
}
and comment out the calls for loading iPad classes and views
The answer to this varies based on how you've set up your existing code. If for example, you perform run time checks for the current hardware E.g if ([[UIDevice currentDevice] userInterfaceIdiom] == UIUserInterfaceIdiomPad) and change the UI based on the result of this, then you'll have to redo some code because even if the app only has an interface for iPhones, that condition would still evaluate true on an iPad.
Then another option is to have your classes split between interfaces. This is probably the best method when done right. By that I mean really sticking to the MVC paradigm and making your two interfaces separately, then linking each to its own controller object and then putting as much reusable logic for your app in one universally accessible object somewhere.
If you're done this the second way I've mentioned, you shouldn't have any trouble. Simply by pointing the project toward a storyboard for the iPhone/iPad versions of the project, the correct class files are loaded etc. Which leads me to the direct answer to your question.
Modifying the "Targeted Device Family” is all you really have to do provided you've set up your project in the second way I listed. And furthermore, there shouldn't be any concern that jailbroken users will access the iPad files. They can get in, but they're all compiled anyway and 99% of people don't know what to do with that big blob of gibberish.
And even if they did, I don't think anyone is going out of their way to try to find iPad versions of iPhone only apps. They know that if an app has a completed iPad version, it will just run on their iPad.
you do not need something else besides modifying "Targeted Device Family" property. I see little possibility that launching iPad mode is possible even on jailbreaked devices, but you can, for example, remove iPad files (and dependencies for them) from your project for iPhone build. I still think this is not necessary step.
I wrote an iPhone app. Then, I changed the interface a fair bit, added higher res images, and made an iPad version of it. In a perfect world, I would like for anyone who buys the iPad version to get the iPhone version for free (though not conversely). Since Apple doesn't seem to have a way to do that (right??), my next favorite solution is to make the iPad version include the iPhone version somehow.
I know that I could just convert the iPad version to "universal", but since the face of the app is so different, that seems like a real pain. I have many view controllers and they are almost completely different between the two versions. Some of the methods are the same, but only about 30%. Is there an easy solution along the lines of this:
Check if device is iPhone or iPad
If iPhone, then use one group of files
If iPad, then use a different group of files
Thanks in advance!
Try creating a new project in Xcode and choose to make it a universal app. In the default way Xcode lays it out, there is a distinct divide between the iPad and iPhone versions. You can make the two versions of the app as similar or different as you want.
In addition, you can check which device you are running on at runtime by using UI_USER_INTERFACE_IDIOM(). Currently the two values for this are UIUserInterfaceIdiomPad and UIUserInterfaceIdiomPhone.
The "easy solution" you describe is basically how iOS loads Universal apps.
There's no other real way around it. You'll have to merge your two projects into one again to do what you want.
The first problem will be that some (many?) names of classes will be common between both projects. You can save yourself some pain by using the "Refactor..." functionality in Xcode to change the names of the classes in one project (say, your iPhone app, since it's older) before you merge them together. The second problem will be your Info.plist; you'll need to ensure that the correct "Main nib file base name", the correct supported interface orientations, icon files, and so on are set to correct values for both iPad and iPhone respectively.
I'm whipping up a short specifications/requirements document for a small prototype iPhone app project. Describing the basic functionality and behavior is not an issue for me. But, since my mobile application and iPhone development knowledge is very weak, I'm not really sure what else should be in such a document regarding best practices and such.
Example: In my programming world (server side Java), when spec'ing a project for outsourcing, I state that the project must pass static bug analysis by FindBugs.
Example: I understand that there are API calls Apple does not want app developers invoking. These can be cause for having an app rejected from the app store. But I'm not sure how to say that we want Apple's guidelines respected. (I don't even know how to test for that.)
What should I include in a two-page requirements and specification document that is specific to iPhone app development?
These are some points you can mention
1. The application should be developed based on Apple's user interface guidelines
2. There should not be any private API call inside the project which makes the application rejected from apple
3. There should not be any memory leak or excess memory allocation issue during the application running state
4. The application should be supported in all iOS after [your option]. (It mainly depends on the features used in the application)
5. The application should be supported in iOS 4
6. The application should work properly on iPhone 4
Hope this helps
A private API wont be mentioned in any header file or in the documentation so one way to test for that would be to manually go through the source files and search for the functions used in the headers and documentation to see that they are there. It's really not feasable if the project grows but for a small app it could work :)
In addition to the things already mentioned here, I'd add a few more:
The app should work fast, no action should give the user the feeling, the device is doing something
Everything that takes a while should be run in background and even better, be cancelable
Make sure you use animation only where it makes sense but not too seldom. A smooth feeling is most important for users.
These things also imply that you try to minimize application startup time.
There are often tricks to work around performance issues. The feeling a users gets from your application is not how fast it is, but how fast if feels. In my opinion this is the single most critical requirement, besides obvious ones like no crashes etc..
What's the problem with using a private API?
Moreover, I would add that it will be tested on iPhone 3G, 3GS, iPod, 4, all with iOS4 and 3.
I am working on a project where the iPad will be used for a specific purpose, and only run one app. When the device starts up, I want my app to run, and I want to override the home button so that it does not quit the app (like the iPhone/ iPod demos in the store).
I have seen bits and pieces of this functionality, but am unsure how to implement it. I realize that it would have to be on a jailbroken device, and the client is fine with that.
Any ideas?
Thanks!
Thomas
Edit 1: I found this site, which explains some iOS daemons. I'm still researching, so I'll just keep posting what I find.
Edit 2: I found Saurik's IRC channel and asked around in there. One of the participants told me that it is possible, but probably not as simple as I thought. I am still doing some digging around in the iPhone 3G filesystem now just to get the feel of what certain things do.
The project has been scrapped, but I'm still looking for help on this though....just cuz I'm interested lol.
Here's my progress on the issue. Question's still not completely answered, but I'm making some headway :-)
I've been researching Jailbreak and the iOS filesystem as well. That has helped my understanding of the issue some.
Without jailbreaking this would not be possible.
There has to be something in /etc somewhere that runs through all the things that start up, just like on Linux.
It so happens that my current ipod touch has a WALD screen after me manually deleting a few mp3 files. Some anti mp3 mocking code policing it, and not liking me touching the mp3 file structures... otherwise I'd look for you right now.
Do you know how to ssh into your ipod/iphone?
Well, I believe Apple itself uses this on the iPads running at the Apple Stores (those showing animations about the products where you can ask to talk with a blue shirt).
I would look for something on the official IPCU (iPhone Configuration Utility) to check if there is an option for auto-loading apps on boot time.
If not, try to get friends with someone working on an Apple Store and get some hints on how they run their app on those iPads.
you can add the "voip" key in the information plist.
This is backed up by Apple:
You can also see this sample project:
https://github.com/lithium3141/BootLaunch
PB.
Curious what practices people have learned before making their final build and submitting to the App Store? Aside from switching from Debug to Release & commenting out calls to NSLog what other basic and/or not so basic things should we be watching out for?
This is a good question and I'd like to restate some of the answers and add a few of my own. I've made this answer Community Wiki, feel free to add to it.
Delete the app from your device, turn off WiFi, off cellular data, now install and test app. Does it work properly (as much as it can without Internet)? Does it at least tell the user that a network connection is required (if it is) or does it crash?
If you use CLLocationManager: Delete the app, fresh install and run, but do not allow app to have Location Data. Does the app behave well or does it crash? Does it at least tell the user that it can't run without location data (if that is a requirement)? Does it work on an iPod Touch that does all geo location using WiFi only?
Run the app in the simulator and for each view controller do the following steps: (a) From the iPhone Simulator menu select "Hardware" --> "Simulate Memory Warning", (b) now navigate around your app to other view controllers and see if everything is working, (c) repeat test for another view controller.
If you support older firmware (ie: iOS 3.1.3), install your app on a device running 3.1.3 and test it there (if you don't have one, use the 3.2 simulator).
Start your app while on a phone call or when Personal Hotspot is active. Are all the screen layouts correct (the status bar is 40px high instead of 20)? Did the bottom 20px of the view get pushed off the screen or did it resize correctly?
Accept a phone call while in your app, does it resign active and resume properly? Do sounds from your app stop playing while in the phone call?
Start your app while playing music, does the music continue to play? Do your sounds mix properly or fade the music appropriately?
Test performance on a slower devices with limited RAM such as: iPhone 3G (128MB RAM, 412Mhz CPU) or iPod Touch (1st or 2nd gen).
Run the Clang static analyzer and fix (or at least understand) every warning.
Make sure NSZombiesEnabled is NO in the environment variables (caution: not sure if this is still a problem)
A few things:
I actually recommend not creating a build configuration called "Distribution" as Apple specifies, because I often am creating ad hoc builds for beta testers. I create two build configurations, one called Ad Hoc and one called AppStore, so I'm not confused. The only difference between the two is the presence of the Entitlements.plist file for the Ad Hoc build. This way I can test as closely as possible what I will be submitting to Apple.
Most developers are optimists. That's why we are working weekends to create an app that we just know is going to make us a millionaire. Before submitting though, be a pessimist. Imagine everything that can possibly go wrong, and double check it.
Don't assume anything. Don't assume that that tiny little change you made to the app won't affect anything else. Murphy's Law says that that tiny change will cause your app to crash on all iPod Touches or something. Test, test, test thoroughly between the final code edit and Appstore submission. If you have to make a tiny change, then repeat until it's perfect.
Remember that if the app doesn't crash for 99.9% of your users, then 1 out of every 1,000 downloads will result in a 1-star scathing review.
I use Clang static analyzer, Leaks and Object Allocations during development, but I do an extra run of these tools before submission just in case.
If you don't have an older device, get one, because the 3GS performance is significantly better and you may miss some important performance issues.
Test your app with the following configurations when network or location are applicable:
iPod Touch
iPhone 3G
iPhone 3GS
iPhone in Airplane mode
iPhone with Wi-Fi
iPhone with EDGE
Call the phone while using your app
Instead of switching to Release, I switch to "Distribution". It's a copy of Release, but that's is how I got taught by some Apple doc and iPhoneDeveloperTips.
Important points:
After the final build, but before you rush off to zip up your app, open the bundle using the Finder's Show Package Contents. Due to some bug in the MacOS, which bit me in versions prior to Snow Leopard (and it might still be there), if you zip up too fast (using the Finder's Compress or Archive menu item), some of the resources have yet to be flushed out into the file. When you do a Show Package Contents, the contents get updated. The way you would notice this problem is that the size of your compressed app would be between a fifth to a tenth or less of the expected size. You might think to yourself, "hey, that zip utility really does a great job of compressing", but that's not the case. This problem would occur at this point instead of during testing mainly because you are doing a "clean all" build and all the resources and contents of the app bundle are starting out empty and then being filled by Xcode. And for some reason, even after Xcode is done creating the file, the contents are still not actually there, if you compress, but would be there if you looked at them (sort of a reverse Heisenberg). Beware.
Another area I spend a lot of time on is to make a nice backup of the sources, after I have committed all the latest changes to SVN, made a new branch, and tagged the file. I also like to have my version number match my SVN build/commit number so I always know which SVN version matches my release. I have those two version numbers in my info.plist and can be pulled up by the app user when they hit i for info. For example, a current info.pist includes:
<key>CFBundleShortVersionString</key>
<string>2.0a1</string>
<key>CFBundleVersion</key>
<string>346</string>
There are different thoughts on how to use the CFBundleVersion. This is my way. Also useful is the command line utility, agvtool.
Once the app is built, after compressing so you're not actually making any changes to the compressed version, go check the app file and make sure it is signed with the right distribution cert and not your adhoc one. Learning to use the command line utility, codesign, is helpful for this kind of checking and debugging. By making the compressed copy first, you ensure that you're not in any way going to change the final copy that Xcode has handed you and that you will upload to itunesconnect, if all looks well.
Other things to remember are the app icon, the various other icons and graphics you need for the iTunes store, the info.plist, and the fact that when the uploading of the app fails with a cryptic error message, it usually has to do with one of these pieces being missing from the compressed file you are building (those pieces that belong in the app bundle).
Look into this check list document # Github
https://github.com/bapu/AppReleaseCheckList