I created a new Xcode Preference Pane project which I aim to run in the System Preference application.
I have made one modification to the project's build settings:
Changed Base SDK to Mac OS X 10.6 from 10.7 (Since I want to keep compatibility for Snow Leopard).
I have a nib file and NSPreferencePane subclass, yet Xcode doesn't allow me to run the application (only build it, the Run option is disabled).
My environment specs:
Macbook Pro 2010
Mac OS X Lion (10.7)
Xcode 4.2
With Xcode Schemes you can now do this very nicely. Edit the Run action of the scheme like so:
Set the Executable to System Preferences.app
Go to the Arguments tab and pass a launch argument: $USER_LIBRARY_DIR/PreferencePanes/$FULL_PRODUCT_NAME
Now expand the Run/Debug scheme and click on "Pre-actions"
Add a script pre-action with the following body: cp -a "$TARGET_BUILD_DIR/$FULL_PRODUCT_NAME" "$USER_LIBRARY_DIR/PreferencePanes/"
Bingo. Run will now launch System preferences and go directly into your prefpane.
By default, schemes are per-user and thus you are probably excluding them from your repository, and even if not other users won't see them. Go to "Manage Schemes..." and mark the prefPane scheme as shared if you want others to get these settings.
NB: For some reason I seem to get random crashes when you launch the prefPane as an argument. Just turn off the argument and manually launch once - from then on you can use the argument again...
Related
I have a macOS application that uses CGEventPostToPSN to send keyboard commands to TextEdit.
Whenever I compile a new version of the app, I'm unable to send keyboard commands.
I have to go into System Preferences -> Security -> Accessibility, then remove and re-add my application.
Every time I compile a new version.
Is there some way to circumvent this during development?
Yes, I worked on a project with this same problem. We never got around to doing it (disclaimer!), but our working theory was that if we enrolled in the Apple Developer Program and signed our development macOS builds with a Developer ID certificate, this problem will go away.
(The thinking was that it was probably Gatekeeper not being able to link one build to the next since there was no shared certificate for continuity.)
Note: This doesn't mean you have to distribute in the macOS App Store. You might look into notarization though.
I have created an XCode 8 Extension (For Deleting Lines, Like Sublime and Android Studio). I have code-signed it and it works as expected in the Gray Xcode Test thing.
I haven't seen a single instruction on how to get it to run with "Regular" XCode? What should I do to be able to use my extension whenever I start XCode?
After somehow getting this to work (once) by restarting my computer, I have finally found some working instructions on how to use an Extension with XCode 8. These are the steps:
Enable target signing for both the Application and the Source Code Extension using your developer ID.
Product > Archive.
Right click archive > Show in Finder.
Right click archive > Show Package Contents.
Open Products, Applications.
Drag "YourExtension".app to your Applications folder.
Go to System Preferences -> Extensions -> Xcode Source Editor and enable this extension.
Restart XCode if necessary
I had a few automator actions developed under OSX 10.6, which successfully executed under automator without an issue. The binary products of these actions continues to work under OSX 10.7 (Lion), but compiling them from source fails.
In trying to debug this issue, I created the dirt simple "Hello, World" action, but it will not successfully execute in automator, both the ObjC and Applescript variant getting "launch path not accessible", no matter where in the workflow they are placed.
The development path I have followed is:
In XCode 4.1 (build 4B110, from the App Store), create a new project, and select Automator Action" as the type
Set Output type to com.apple.cocoa.string
Under the ObjC variant, change the runWithInput:error method to return #"Hello, World!" Under the AppleScript variant, change the runWithInput_fromAction_error_ method to return "Hello, World!"
Compile the action via the run arrow
Open the new action in finder via right click on the action under the Products group
Double click on the action and let automator install it
In automator, create a single item workflow (but have tried multi-item workflows) with the new action
Execute the workflow via the run arrow and receive the "launch path not accessible" error
I have tried restarting xcode, restarting automator, removing my ~/Library/Automator directory after shutting down automator, and combinations of the above without change. At this point, however, I'm out of ideas.
Thanks for your help.
As per the comment recommendation, and for posterity, the issue appears to be localized to XCode 4.1. XCode 4.2 betas do not exhibit this behavior and appear to operate as expected following the workflow I outlined in the question.
after stopped searching for it, found an tutorial but can't test it anymore because I already upgraded to Xcode 4.2. It would be nice if someone could verify that:
http://macosxautomation.com/automator/xcodefix/index.html
I have created a minimal OS X boot stick (basically the Snow Leopard DVD with all the packages and installer stripped out). I've written a basic Cocoa app launcher to launch other apps that I put in the Applications folder (the minimal install lacks Dock and Finder).
When I try to launch an app I get this error:
LSOpenFromURLSpec() returned -10810 for application (null) path /Applications/MyApp.app
Where "MyApp.app" is the app I tried to launch. I've tried this with both NSWorkspace's openFile method and the UNIX "open" utility and I get more or less the same error. One way that launching an app works is if I just execute the main executable of the app itself. (e.g. /Applications/MyApp.app/Contents/MacOS/MyApp). However this method is kind of inconvenient as it stalls the launcher until the app I launched exits. Any alternate ways to launch an app (or fix the LSOpenFromURL error)?
Thanks
Found a workaround:
/Applications/MyApp.app/Contents/MacOS/MyApp >/dev/null 2>/dev/null &
Using that command starts apps without stalling the launcher.
open relies on Launch Services, which relies on the Finder. Your script workaround starts a new background process executing the application's code with its standard out and standard error open to /dev/null. That should work fine.
The C equivalent under Mac OS X would be to either posix_spawn or fork/vfork then exec the executable file.
i have installed the latest iphone sdk 3.0 beta 5, and trying to submit the first application build from this sdk,but when i upload to itunes connect, it give me the message "The binary you uploaded was invalid. The value provided for the key MinimumOSVersion is not acceptable." and cannot be uploaded. therefore i edit my info.plist file in the project and set this key to 2.2.1,like
<key>MinimumOSVersion</key>
<string>2.2.1</string>
and upload again but it still return the same message,have anybody met the same issues and how to get rid of this?
You SHOULD NOT specify MinimumOSVersion in your Info.plist. From the Information Property List Key reference:
MinimumOSVersion (String - iPhone OS, Mac OS X). When you build an iPhone application, Xcode notes the target OS (as determined by the Base SDK selection) as the MinimumOSVersion property. Do not specify this property yourself in the Info.plist file; it is a system-written property. When you publish your application to the App Store, the store indicates the iPhone OS release on which your application can run based on this property. It is equivalent to the LSMinimumSystemVersion property on Mac OS X.
What you need to do is change the Deployment Target setting in your project. The Deployment Target specifies the minimum OS you would like your application to run on. This is regardless of the SDK you build against, which should always be the most recent SDK so you can ensure your application runs correctly on the most recent OS version available. So, in short:
Set the Base SDK to be the latest OS available
Set the Deployment Target to be the earliest OS you'd like your app to run on.
Manually editing the Info.plist file is really just fooling the App Store into thinking your app can run on an OS it isn't built to run on, which could yield unpredictable results.
Please read the notice in the iPhone developer centre. You CANNOT use the iPhone 3.0 SDK to build apps for the App Store at the moment, not even if you compile them for the 2.x OS. You have to compile an app using the 2.x SDK to submit it to the App Store.
You can install both sets of developer tools side by side. When you get to the screen where you select which parts of the package you want to install, you can select an alternative destination for the install.
I had the same problem. Heres how to fix it!
My project was called SuperTennis, so I clicked the project in xcode, and clicked Get Info. Under the General tab, change "Base SDK for all iPhone configurations" to iPhone OS 2.0, then go into the build tab, and change "Base SDK" to "iPhone OS 2.0", then build it for your device. Reveal the app in finder, and then continue on, to upload it. Email me at ryan2925 at gmail.com if you want some more help. I hope this works for you, and anyone else reading.
I got this error when I finally upgraded things from 2.2.1 to the 4.0 SDK, and tried to use an existing project.
I had to:
Click on the project in XCode, then click on Info.
Click 'Build'
Pay attention to what 'Configuration' you are setting. Are you accidentally setting distribution when you are trying to debug?
Set 'Base SDK' to the highest possible.
Change 'Target Device Family' to whatever it is you are doing.
Set 'iPhone OS Deployment Target' to your device's OS (you can check by going to Window > Organizer).
My main time sink was setting my distribution settings when trying to debug and not realizing it.
Try this:
ARMV6: before iPhone 3GS
ARMV7: including and after iPhone 3GS
"Proj." and "Target(s)" right-click, Get Info. Select:-
Base SDK: iPhone 4.0 (latest s greatest)
Standard: ARMV6, ARMV7
Uncheck build for Active Architecture
Deployment Target: 4.0 (not older ones 3.1.3; you don't have the SDK if you upgrade to 4.0)
Compiler section: Ensure that both ARMV6 and ARMV7 checkboxes are ticked under Generate Code, Thumb section.
The binary output is slightly bigger as it is generic code that supports both architectures.
If you want to support ARMV7 only, don't check ARMV6 in compiler section, selection code optimised for ARMV7, check active architecture only. In info.plist, add armv7 in UIRequiredDeviceCapabilities items. This field already exists in info.plist and probably has other system requirements auto-specified.
Right click on your project and go to your build tab. Near the top of the list you can specify your Base SDK. This is the minimum you will compile against. After this your build settings drop down will have the older versions. When you go to make your distribution make sure you aren't using 3.0 cause that will cause your binary to get rejected (as you found out).