Disable home button without rebooting device - iphone

I want that after installing my app from an OTA the home button of the device will not work at all so that user is unable to come out from the App. My digging led me to following results
A) I got a way to disable home button by a "mobileconfig" profile but it needs to restart the device and user have to open my app just after booting, i want to do this without restarting with something like Private Frameworks on non-Jail-broken devices. I want to know is that possible for non-jail-break devices?
C) If it is not possible to disable home button with Private Frameworks, then is there any way to open an app just after booting the device?, since certain jailbreak apps/ processes are loaded upon startup.
[NOTE: I don't want to submit my app to iTunes.]

In iOS6, there's a feature called "Guided Access", which will allow device owners to lock users (like toddlers and school kids) into an app.
This explains the Guided Access for iOS 6 apps.

The official answer of this question is "you can not disable home button in ios devices it is os level architecture and your are not authorized for it."
You need to dig to operating system flow to make any changes which might be quiet tough.
well, if you change you sight though it than there is one open and simple solution for this in ios 6 known as Guided Access.

If you are able to jailbreak your device create a LaunchDaemon or use an existing one. The LaunchDaemon is a file in plist format that is called upon rebooting and starting your device. You will also need a file named open created by K3A
Download open from here
You will need to move open to /usr/bin/ or you can put it inside your app does not matter but set permissions to 0755 and root:wheel
Now on to the LaunchDaemons, they are stored here
/System/Library/LaunchDaemons
Here is an example.
Lets say you name the LaunchDaemon
com.gauravstomar.test.plist
Where it says com.bundle.identifier put your apps identifier you may also find it in your Info.plist inside of your apps directory where it says CFBundleIdentifier
Now inside the plist insert the following information
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.gauravstomar.test</string>
<key>ProgramArguments</key>
<array>
<string>open</string>
<string>com.bundle.identifier</string>
</array>
<key>RunAtLoad</key>
<true/>
<key>StartInterval</key>
<integer>1</integer>
</dict>
</plist>
Label has to be the same name as the LaunchDaemon.plist excluding plist extension
ProgramArguments is what calls the file open and launches the app
RunAtLoad makes this plist launch upon reboot
StartInterval will make the LaunchDaemon.plist open back up after 1 second if the user exits the app, if the user is still in the app nothing will happened
Make sure the permissions for your LaunchDaemon is set to
0644 root:wheel
You can still use your mobileconfig so that the home button is disabled. Once assessment is complete you can disable the LaunchDaemon so that the app stops relaunching itself with the following command
launchctl unload/System/Library/LaunchDaemon/com.gauravstomar.plist
Let me know if you need any more help.

Without jailbreaking, the app is sandboxed. The app simply does not have access to mess with the home button. And you really shouldn't be messing with the home button.
In addition to "Guided Access", you can also make use of "Restrictions", which will allow you to disable everything accept opening your app. You can disable Apple specific apps including Safari, and prevent users from installing apps, deleting apps, making purchases, etc...
We have a number of iPod touches with a ticket scanning app we rent out to our customers. We make use of "Restrictions" to disable everything besides our app. The most helpful restriction thus far is preventing people from deleting apps - It's incredible how many people will accidentally delete an app, even after the warning prompt.

Related

App Store submission shows app icon issues in Xcode 11

I was recently not able to submit the app to Appstore and its showing 3 errors and the thing is i have all the app icons placed in Xcode as you can see in my screenshot correctly but this error comes. I have been trying for many hours to solve this issue. Anyone has idea what is wrong and how to solve? I have included all the icons in my assets folder as you can see . I even checked the dimensions and even deleted assets folders and created new . But still the error comes. How to solve this issues?
Missing App Store Icon. iOS Apps must include a 1024x1024px App Store
Icon in PNG format. Without providing the icon in the Asset Catalog or
via iTunes Connect, apps cannot be submitted for App Review or Beta
App Review
Missing Info.plist value - A value for the Info.plist key
'CFBundleIconName' is missing in the bundle 'com.abcd.iphone'. Apps
built with iOS 11 or later SDK must supply app icons in an asset
catalog and must also provide a value for this Info.plist key. For
more information see
http://help.apple.com/xcode/mac/current/#/dev10510b1f7
XCODE ASSET FOLDER
Added the info.plist screenshot :
Make sure your asset catalog is in fact part of the app target.
Make sure your build settings point to the AppIcon image set.
And make sure you don't have multiple asset catalogs with multiple AppIcon image sets, as the build system will not know which one to use.
You should be able to open the built app package in the Finder and see the CFBundleIcon entry:
<key>CFBundleIcons</key>
<dict>
<key>CFBundlePrimaryIcon</key>
<dict>
<key>CFBundleIconFiles</key>
<array>
<string>AppIcon60x60</string>
</array>
<key>CFBundleIconName</key>
<string>AppIcon</string>
</dict>
</dict>

MenuApp in Swift 4 to Run on Login for High Sierra?

My app is a menu app that sits in the menu extras running in the background, and I'm trying to make it to run on login. What's the latest recommended practice to achieve this for High Sierra using Swift 4?
According to Designing Daemons and Services, there are four different background processes on MacOS.
Since I would want my app to run upon user login, I guess it's going to be either login item or launch agent. However, for Login Item, it seems there are two ways to implement Using the Service Management Framework or a Shared File List.
I first attempted to use Shared File List, based from this example from github. However, Xcode throws bunch of deprecated warnings and errors indicating it doesn't support in Swift 4 and latest MacOS anymore.
Then I got it to work using using SMLoginItemSetEnabled from this guide. However, using this method, my app doesn't show up inn the system preferences under the login items.
Is Shared File List method is completely out of option for Swift 4 and High Sierra?
What about launch agent? I couldn't find much guide on making an App as a launch agent using Swift. I would appreciate if someone could share some code.
Thanks!
I would suggest creating a launch agent. Login items are soooo 2010 ;).
There's really no API for creating a launch agent (or other launchd services). The steps are, basically:
create and write the appropriate ~/Library/LaunchAgents/com.your.agent.plist file
execute /bin/launchctl bootstrap gui/501 ~/Library/LaunchAgents/com.your.agent.plist
(where 501 and com.your.agent are the user's UID and your launchd identifier)
The second step is somewhat optional; the system will see your .plist file and start the agent automatically the next time the system restarts. So you can kick start it by just manually launching it the first time. But if you want it to be immediately registered with launchd (so it will automatically get restarted if quit, for example), then I know of no other way than to run launchctl once to register it. (Similarly, you'll need to run launchctl bootout ... to shut it down when it's time to uninstall it.[1])
The details of the .plist file can be found in man launchd.plist, but here's a simple example of a LSUIElement app called "Menu" that runs in the background whenever the user is logged into to a GUI session:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>KeepAlive</key>
<dict>
<key>SuccessfulExit</key>
<false/>
</dict>
<key>Label</key>
<string>com.my.menu</string>
<key>LimitLoadToSessionType</key>
<string>Aqua</string>
<key>Program</key>
<string>/Applications/Menu.app/Contents/MacOS/Menu</string>
<key>RunAtLoad</key>
<true/>
</dict>
</plist>
To create the .plist, all you have to do is populate a property list dictionary with these values and call dictionary.write(to:atomically:) to write it where it belongs.
Launch agents are regular user processes so none of this requires any special privileges, although I'm not sure about writing to ~/Library/LaunchAgents from a sandboxed app.
Since the user doesn't normally fiddle with ~/Library/LaunchAgentsor launchctl your application will need to provide a UI for installing and uninstalling the agent. For a status menu item app, this is usually as simple as a preferences checkbox to "Show in Menubar".
[1] bootstrap and bootout were added in 10.11. If you have to support earlier versions of macOS there are workarounds.
The recommended way especially for a sandboxed app is the Service Management Framework (SMLoginItemSetEnabled) and a helper executable located in ./Contents/Library/LoginItems
Of course the application does not appear in Login Items of System Preferences because the behavior is supposed to be controlled in the app itself.

Sandbox entitlement to script iTunes via NSAppleScript

I'm trying to script iTunes from NSAppleScript in my Cocoa app in order to add a file to the library.
In my entitlements file, I added the following:
<key>com.apple.security.scripting-targets</key>
<dict>
<key>com.apple.itunes</key>
<array>
<string>com.apple.itunes.library.read-write</string>
</array>
</dict>
I then call the AppleScript like this:
var error: NSDictionary? = nil
let appleScript = NSAppleScript(source: "tell application \"iTunes\" to add (POSIX file \"\(path)\") to library playlist 1")
let result = appleScript?.executeAndReturnError(&error)
but it fails with an error -10004: iTunes got an error: A privilege violation occurred.
I tried capitalizing iTunes both ways (itunes and iTunes) but nothing seems to work. I also tried adding, on top of the read-write entitlement, the read entitlement. Finally, I tried adding read and write access to the user's Music folder (where the iTunes library is stored) and this didn't help either.
Is there another required entitlement that I'm not aware of in order to script iTunes?
I found this link in my search for a solution (link) but it requires the user to select a specific folder in his Library folder to give the application user-selected file access and then it requires the script to be in a separate file which is 2 things too many for what I want to do. I don't trust the user regarding the management of the script files and I don't need a file for 1 line of AppleScript code. Another disadvantage, as I understand NSUserAppleScriptTask is that you can't persist a script's state across multiple calls, which is not a problem in my case but could be for someone else.
Thanks
After contacting the Developer Technical Support of Apple, I was able to solve this problem, which is actually 2 problems in one.
First, the entitlements need to have the bundle identifiers properly cased. For iTunes, the entitlements must be like this (note the capital T in iTunes):
<key>com.apple.security.scripting-targets</key>
<dict>
<key>com.apple.iTunes</key>
<array>
<string>com.apple.iTunes.library.read-write</string>
</array>
</dict>
Then, the privilege violation will occur unless the AppleScript code includes of source 1 at the end like this :
tell application "iTunes" to add (POSIX file "your/path/to/mp3.mp3") to library playlist 1 of source 1
There you go!

iPhone Entitlements problem with XCode 4 for Ad Hoc distribution

I have reread all the documentation and postings on Ad Hoc distribution and still have a problem. If I try 'wireless' distribution (with a .plist and .ipa file being downloaded using Safari) the app starts to download, the icon is drawn correctly and the name changes from 'Installing..' but when its about 90% complete I get an 'Unable to Download ...' alert.
If I use the iTunes method of transferring the app I get 'The app "xx" was not installed on the iPhone "xx" because the entitlements are not correct.'
Q1: I have read that you no longer need to separately add the .mobileprovision file because XCode (I am using 4.0.1) adds it to the bundle - is this true ?
Q2: when I 'download' the .mobileprovision in safari (on the iPhone) it merely displays it as text. Is this symptomatic of my problem or an irrelevancy ?
Q3: does this problem concern the Entitlements.plist ? I can't find any documentation from Apple or any blogs that relate to what I see when editing this file with XCode 4.0.1. If I follow the instructions (New->New File->Code Signing->Entitlements) I get a default file with only a 'Can be debugged' Key. I have tried setting this to NO, adding a get-task-allow Key (replacing the existing - presumably Can be debugged is the same key ?) adding my application-identifier, and adding an iPhone Entitlements Dictionary with the above two keys in (as per Apple's documentation).
Q4: what is the suicide rate amongst iPhone developers trying to get Entitlements and Code Signing working?
To cut down on suggestions I've seen for similar questions:
I do have Code Signing Entitlements set to my Entitlements.plist for Distribution and Release.
I have tried restarting XCode, rebuilding, archiving etc
I have tried restarting the iPhone
I have gone back to the iPhone
Update:In XCode 4.0.1 there is a menu option when the Entitlements.plist is being edited (Editor->Show Raw Keys and Values) which will toggle the key from 'Can be debugged' to 'get-task-allow'
The entitlements file should be:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>get-task-allow</key>
<false/>
<key>application-identifier</key>
<string>$(AppIdentifierPrefix)$(CFBundleIdentifier)</string>
<key>keychain-access-groups</key>
<array>
<string>$(AppIdentifierPrefix)$(CFBundleIdentifier)</string>
</array>
</dict>
</plist>
this works for wireless too.
Why on earth the default one doesn't have all this in is something only Apple can answer.
I can't see how to edit the raw text of a plist in Xcode so edited in TextEdit.
Code signing entitlements are no longer necessary for Ad Hoc builds in Xcode 4 - see details notes in Apple Technical Note TN2250
I just wrote a blog post outlining all the steps to successful ad hoc distributions in Xcode 4 which may be helpful. http://www.musicalgeometry.com/?p=1237
Entitlements.plist should be added in project and there should be only get-task-allow key inside it.
When debugging on device using developer profile, It should be checked
When building using Ad-Hoc or Distribution profile, It should be unchecked
Regarding Q4: If you like you can increase it by just doing... but I don't recommend it.
If you right click on the plist file in the project navigator, and select "Open As" then "Source Code", you can edit it as plain source.
Maybe they made a shorter version of Entitlements.plist in xcode4. The default Entitlements.plist does not contain the 'application-identifier' and the 'keychain-access-groups' keys, but if you change the value of the 'Can be debugged' key via the 'ASCII Property editor' it really changes the value of the 'get-task-allow' key in the background...
I tried setting the entitlements parameter "on" or "off", re-download my ad-hoc provisional that had been used for as long as I can remember, and tried hundreds of other combinations. None worked for me until...I went to the provisional portal and recreate a new provisional.
What really got me to stay up until 4:00AM and wasting hours of time that I did not have was how I created the ad hoc provisional. On Apple's iOS provisional Portal page, if you click on the "provisioning" on the left side bar, you will see 4 tabs: "development", "distribution", and the other two. I used to use my provisional created under the "development" tab and added all the test users' phone UUID. That had worked for me for years until the xCode 4 came along, and I was stupid enough to jump on board too fast. Apple engineers had always given me a surprise "mid-night" party every time xCode had an update. And they will wait long enough for me to forget this experience and release the next one.
The solution that worked for me was to create a provisional under the distribution tab. When you create a new provisional here, you have the option of selecting "ad hoc" as the "Distribution Method." After used this provisional on xCode project and target build setting, and turned off "can be debugged" on the entitlements, I then could install via iTunes or via OTA. I hope this tip might help someone save a few gray hair.

Lock-down iPhone/iPod/iPad so it can only run one app

We'd like to 'lock-down' an iPhone/iPod/iPad so that the user can only run one app (we've developed this app internally). I'm guessing we'd be looking at jailbreaking, and then replacing (?) the default Springboard app.
Can we do this? If so, how?
EDIT: iOS 7 now includes an 'App Lock' payload as part of the device configuration profile. From the Apple docs:
"By installing an app lock payload, the device is locked to a single application until the payload is removed. The home button is disabled, and the device returns to the specified application automatically upon wake or reboot."
Read more about it here:
https://developer.apple.com/business/documentation/Configuration-Profile-Reference.pdf
It is possible to put an iPad or iPhone into 'Store Demo' mode so that the home button and swipe to home gesture is disabled. If you have seen the iPads in the Apple Store running the smart sign apps then you will know what I mean.
It is actually pretty trivial to make this work, all you need to do is install a correctly formatted mobile config plist over the air from a web server.
To deliver your config from the web all you have to do is direct the iPhone to a url containing the profile. Just open the link to your .mobileconfig file in safari. If you don't have web space you can just use dropbox public folder URLs or switch on your mac webserver.
It's possible that you can load the config using IPCU too but I have not tried this. This config file will not load in the iPhone Configuration Utility as it uses keys that IPCU doesn't know about. You can combine this with whatever other enterprise configuration profiles you have in play.
EDIT: #cocoanetics pointed out that IPCU is not required to remove the profile. However note that to get your device back to normal you would need to do the following:
Reboot
Open the settings app FIRST - don't open anything else or you will need to reboot again
Settings->General->Profiles->[your profile] remove it.
Reboot
you should be back to normal.
I have included an example plist that will disable the home button and lock your device into the app.
BEWARE
Once this profile is installed the first app that is launched when the device is rebooted will be the only app that will run until you reboot the device again.
As #Cawas has said this completely disables the ability to return to the home screen (unless your app crashes) including accessibility assistive touch.
Note that after installing the profile you must reboot the device (power off, power on) for it to take effect. To remove the profile plug the device into IPCU and delete it then reboot the device. Everything will be back to normal.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>PayloadContent</key>
<array>
<dict>
<key>PayloadDescription</key>
<string>Disables home</string>
<key>PayloadDisplayName</key>
<string>Home Button Lock</string>
<key>PayloadIdentifier</key>
<string>com.hbkill.kiosk</string>
<key>PayloadOrganization</key>
<string>My Org</string>
<key>PayloadType</key>
<string>com.apple.defaults.managed</string>
<key>PayloadUUID</key>
<string>B2D02E2D-BAC5-431B-8A29-4B91F71C9FC1</string>
<key>PayloadVersion</key>
<integer>1</integer>
<key>PayloadContent</key>
<array>
<dict>
<key>DefaultsDomainName</key>
<string>com.apple.springboard</string>
<key>DefaultsData</key>
<dict>
<key>SBStoreDemoAppLock</key>
<true/>
</dict>
</dict>
</array>
</dict>
</array>
<key>PayloadDescription</key>
<string>Disables Home Button</string>
<key>PayloadDisplayName</key>
<string>Home Button Lock</string>
<key>PayloadIdentifier</key>
<string>com.hbkill</string>
<key>PayloadOrganization</key>
<string>My Org</string>
<key>PayloadType</key>
<string>Configuration</string>
<key>PayloadUUID</key>
<string>614D1FE3-F80D-4643-AF6B-D10C4CC8737A</string>
<key>PayloadVersion</key>
<integer>1</integer>
</dict>
</plist>
You may well have moved on from this but I thought I would post this answer here as I came across the question while I was trying to figure out how to do the same thing.
This is a feature of iOS 6 that can be used without hacky attempts. It's called 'guided access'. I small tutorial is here.
EDIT: In case the device's battery runs empty while it's in the hands of a restricted user, the user could reload the device and it will reboot without guided access. However, if you choose to use a password for the device, this shouldn't be a problem.
An alternative to the (admittedly much simpler) approach described by Rick is to:
disable the home button (e.g. physically covering it),
disable the five-finger gesture and screen lock in the Settings, and
install a “Trampoline” to relaunch the app should it crash.
http://www.apple.com/support/ipad/enterprise/
Apple provides enterprise configuration tools which allow control over which applications are permitted etc. This is done through profile management it seems. See link for more details
I agree with a comment from some hours ago: Settings > General > Restrictions should do the trick. If the user can't install anything, can't access Safari or Mail, then there is no reason to ever quit your app.
Block internet access from device (MAC-filter on wi-fi can do the trick). Any other non-internet related problem (music, games, etc) should already be solvable by the current IT infrastructure (unless your developers plays and listen to MP3 at work).
i found one way to quit this home-lock state.
i have install "backgrounder" via cydia which make your app run in background if you press home button for one second or more.
and now, when i longpress home button, i back to the home screen.
that is all.
pay attention on longpress.
Um- wasn't sure if this is an answer or a comment but - the solution that is now part of the question has a weakness - our support staff used this and found that if you "Tap the power button to ‘soft-off’ then hold the home button as you power on and slide to unlock. Sometimes iPad will start on the home page or else XXAPPLCATIONXX will hang and then drop out to the home page. Eitherway X is able to access the home page without the passcode."