- If you enabled photo stream on iPhone and have iPhoto/Aperture on your mac, you can try enabling photo stream on mac. If you didn't install iPhoto/Aperture, maybe you can try MyPhotoStream.
- I strongly recommend flick., which is really easy to use and covered all platforms. It's free and cool!
- Share to iMessage and send to yourself after taking the photo if your iMessage on iPhone is synced with mac.
the geeky way: If your iPad has been jailbreaked, try sshfs in Mac's homebrew. Assume that you have installed homebrew and got root privilege of iPad. Just type
brew install sshfs
in Mac's terminal, and then
mkdir /Volumes/iPad && ln -s /Volumes/iPad ~/Documents/iPad && sshfs root@youripad:/var/mobile/Media/DCIM/100APPLE /Volumes/iPad
(I tried to directly mkdir in Documents and mount iPad's photo directory there but failed. It just didn't appear in the open_file_dialog.)
Last, just choose the photos you want from the open_file_dialog->Documents->iPad.
If you want to unmount your iPad from mac, type
umount /Volumes/iPad
in your terminal.
Enjoy!
This answer is from a public API point of view. Jailbreaking will obviously change this. The permissions are clearly from Android where apps have much more 'free' access to the device—this is what the permissions translate to from an iOS point of view for this site.
Allows the app to change the state of network connectivity
Not going to happen. Apps can only read certain information such as Wi-Fi info (including but not limited to SSID, BSSID, vendor, IP, subnet mask and received/sent total since boot) and cellular info (including but not limited to carrier, country, network type, IP, MCC, MNC and received/sent total cellular data since boot). Apps can not change any kind of network information; they can't even change the Wi-Fi network.
Allows the app to call phone numbers without your intervention. This may result in unexpected charges or calls. Malicious apps may cost you money by making calls without your confirmation.
Nope, making a call using tel:// (or telprompt://) throws a huge dialog box on the screen at the OS level requiring the user to press Call or Cancel. As the dialog is at OS level, the app can't simply bypass it. The connection can't take place unless Call is pressed. Also, as this requires confirmation for each call, the call can't take place in the background without user interaction.
Allows the app to send SMS messages. This may result in unexpected charges. Malicious apps may cost you money by sending messages without your confirmation.
This is the same as calling. Using MFMessageCompose requires user confirmation at an OS level and can't happen in the background as discussed above.
Allows the app to record audio with microphone. This permission allows the app to record audio at any time without your confirmation.
Attempting to access the microphone throws an OS level alert at the time the access is first requested by the app. Subsequent attempts at accessing the microphone will not require confirmation, but only when the app is in the foreground. Using the microphone in the background shows a double-height red status bar to inform the user of the case and using the microphone in the background must be initiated by an app that was in the foreground when the access was requested. Access can be removed from the app at any time in Settings → Privacy → Microphone.
Allows the app to take pictures and videos with the camera. This permission allows the app to use the camera at any time without your confirmation.
Pictures do not require any special permission until iOS 8 and will then throw an alert like the microphone. Video requires the microphone permission, which throws an alert.
Allows the app to read you phone's call log, including data about incoming and outgoing calls. This permission allows apps to save your call log data, and malicious apps may share call log data without your knowledge.
Nope, apps have no access to your recent calls list. The data is not accessible through APIs and is stored outside of any app's sandbox.
Allows the app to read data about your contacts stored on your phone, including the frequency with which you've called, emailed, or communicated in other ways with specific individuals.
Contacts access is granted through an OS level alert. This grants read/write access to the contacts themselves, but no further information. Communication frequency, etc, is not able to be obtained as discussed for the previous permission.
Allows the app to read personal profile information stored on your device, such as your name and contact information. This means the app can identify you and may send your profile information to others.
This can only be obtained through the access of the 'me' card in your contacts, which requires the user grant specific permission at an OS level as discussed above.
Allows the app to access the phone features of the device. This permission allows the app to determine the phone number and device IDs, whether a call is active, and the remote number connected by a call.
An app can access the phone number that the device was activated with using NSUserDefaults. Note that this is the phone number the device was activate with and is not read from the SIM card. The UDID (Unique Device Identifier) was depreciated and Apple no longer accepts apps which access it. I'm not aware of any way to determine whether a call is active using public APIs and definitely not what phone number the call is with.
Allows the app to get a list of accounts known by the phone. This may include any accounts created by applications you have installed.
Accounts such as Twitter and Facebook require OS level permission to be granted to the app. Other accounts such as mail accounts can not be accessed by other apps. Apps that create accounts such as mail clients store accounts themselves as opposed to using the system's storage and therefore such accounts are not able to be accessed unless that app specifically shares such information in that way (for example, logging in to your Google account in the YouTube app also makes your account available in Google Chrome and visa versa).
Best Answer
This question over on StackExchange lead me to Apple's iOS Developer Guide, specifically, the background section. This lists the activities apps are aloud to run in the background, camera access is not one of them.
This would also be a terrible condition for battery life and so it is not surprising that it is not supported. While this doesn't guarantee that none of your apps will try to get access to your camera, you can rest assured that if anyone tried to, Apple would reject their app.
This also ensures that there's no API for background camera access, so unless someone has figured out a way to hack non-jail broken iOS at a very low level, we can all sleep safely with only the watchful eye of Siri upon us.
Edit: Per my discussion with timothymh below, I realized you may have been asking about if you are still using a given app, having take a picture without switching to a new app. With more interesting reading from Apple's Developer Guide, we find that the camera API won't hand you data until a picture is taken or a video completed. Because the camera isn't handled by a daemon, it would be very difficult to be constantly polling the camera for input, even if you found a way past the API to get data without user input. Note I'm not an Apple developer, but from an official standpoint, it appears what you're talking about shouldn't be possible.