I have some problem which is stopping Delphi XE2 from building my project for the OSX platform. I've gone back to basics and created a brand new 'Hello World' console application project. The program compiles/builds/runs fine on the Win32 platform. I add OSX as a new platform for the project, and my remote profile is configured correctly and clicking 'Test Connection' confirms it can see my MacBook. Problem is when I activate the OSX platform, then click 'Build' (under Debug or Release) then the progress window appears as usual and no errors occur, but no output files are created and the 'OSX32' subfolder doesn't get created.
Any ideas what might be the problem?
Solved it - no idea how it got there but in Tools->Options->Environment Variables I had an entry under 'User overrides' as follows :
PLATFORM = Win32
This meant the compiler was only ever building for Win32, regardless of which platform was currently activated.
Related
Using Xcode Version 7.2 on my OS X 10.10.5.
I have a Cocoa application written in Objective-C that utilizes Google's CorePlot library. When I run the app (Product --> Run), it runs perfectly fine.
However, when I archive the project (Product --> Archive --> Export --> Export as a Mac Application), and then run the created '.app' by double-clicking it, the app crashes right away without even loading.
There's no reason for it to crash; the archive was done successfully, and the first window/ViewController don't try to access saved variables that would not be present on a first run.
Basically, double-clicking the app doesn't even open the app icon in the dock or show a window being created - it's like the app won't even open.
This same crash/no loading happens when I try to open/install the app using any of the options under "Export"
It turns out this issue can occur if your app has trouble importing or finding certain classes/files.
In my case, for some reason, when I opened my project and ran the app, it would find CorePlot's CorePlot.h file. However, when I archived the app and exported it to be used on other people's computers, it would not archive and export 'CorePlot.h'.
As a result, my app would crash right away as it could not find 'CorePlot.h'.
I can't seem to get my Today widget (or any extension for that matter) running in the Widget Simulator. The simulator launches and says "Couldn't Open Widget" along with
Failed to find Widget /Users/SomeUser/Library/Developer/Xcode/DerivedData/Build/Products/Debug/MyApp.app/Contents/PlugIns/MyApp.appex
I looked in Console app and I see this as well:
pkd[299]: ignoring mis-configured plug-in at /Users/SomeUser/Library/Developer/Xcode/DerivedData/Build/Products/Debug/MyApp.app/Contents/PlugIns/MyApp.appex: plug-ins must be sandboxed
But it is sandboxed in xcode! It's codesigned, sandboxed and the lot. Even if I try and deploy it on a new machine (registered as a developer machine with my developer provisioning profile), the widgets don't even show up in System Preferences.
Any idea what I need to do?
Okay finally found the problem. I was codesigning my app by hand (which had never been a problem before) since I had an intricate set of frameworks the app relied upon, and needed to hand copy them using a Copy / Runscript post-build script. Any way, it seems starting Xcode 7 at least, this no longer works as expected. The app works and codesign says the app has been signed correctly, but clearly something is happening behind the scenes that's breaking the codesignature. I ended up removing all my manual codesigning stuff and simply using Xcode's 'Copy Framework' post build step and checked 'Sign on Copy'. It's now finally working as expected.
I couldn't stop building & codesigning by hand, so I looked into Xcode build logs and found the difference :) in my case, I just added -fapplication-extension to compiler & linker flags, now it works!
Based on strangetimes's answer here a little more detailed answer:
First select your project and then your App Target (not the extension)
Then click on Build Phases, then on the top navigation on Editor,
here select first Add Build Phase and lastly click on Add Copy Files Build Phase.
That's it. Build again using the Widget Simulator and it should work now.
I have a project with two targets -- an iOS app and an OSX console app. The latter was created using Xcode File->New Target and selecting "Command Line Tool". This console app is used to prep a default database needed by the iOS app -- using CoreData. This has been working fine until I upgraded to Mountain Lion and xCode 4.4. Now when I try to run the command line tool I get a "Could Not Launch -- permission denied" error. I have tried playing around with signing certificates, to no avail. Interestingly if I create a new "hello, world" command line tool in a new project it works just fine -- and it is not signed at all.
I checked the file and it has -rwxr-xr-x permission. In the debugger the app fails on startup even before it tries to access the moms. If I try to run this outside of the debugger at the command line, it ends with a kill 9 message.
Any ideas would be greatly appreciated.
I just had the same problem in my iOS/Mac project. None of the above suggestions helped but I managed to find the correct answer so I'm sharing for future ref.
I had to set code signing to Don't codesign for the MacOSX target. The rest works fine no matter if your deployment target is set to default or not. Don't forget to set your Base SDK to Current OSX and supported platforms to "x86_64 i386".
HTH! Cheers
Also you can get "Could Not Launch -- permission denied" error when trying to launch app on device with password which not unlocked at launch time.
Found the answer. On the Info page I had to change OS X deployment target from Default to 10.8. Default I guess no longer defaults correctly. Anyway it now works.
I also saw this error message when attempting to run a newly created Cocoa app target. The problem was that I had created my app target in an iOS app project, but instead I needed to create a subproject and create the app target in the new project.
Ran into this when I tried to run before creating and installing the provisioning profile.
in my case, I changed deployment target to 10.8(previous is 10.6),and it works.
Short recap for people that came here via the internet search.
On some installations Delphi can't debug FireMonkey applications on OS X. Symptoms: Delphi starts loading the Debug desktop and then locks. Pressing Ctrl+C in the PAServer stops the PAServer and unfreezes the Delphi. The problem was observed with Delphi XE2 Update 4 and OS X 10.7.3.
Longer description is attached below.
I have a brand new Mac Mini (mc815z/a model - i5 2.3 GHz/2GB/500GB/Nvidia Intel HD Graphics 3000). It came with OS X Lion (10.7) which I upgraded to 10.7.3.
On my main computer (Windows 7 64-bit) runs Delphi XE2 Update 4. I've installed platform assistant from setup_paserver.zip (15.656.945 bytes). It installed Java first (Java for Mac OS X 10.7 Update 1). I'm starting PAServer via paserver.command and it seems to be working fine. PAServer says it is version 1.0.2.
Then I've set up a remote profile and it works fine (Test Connection reports success).
When I run (with debugging) a FireMonkey project (I tried various Sample projects and also fresh, minimal FireMonkey application), Delphi starts switching to the Debug layout and then freezes. PAServer reports:
Process Control Server Started pid 343 exe build Jan 15 2012
sentinelFunc 345
[The number in the second line is different every time I try to debug the program.] Nothing happens then. I can kill the PAServer with Ctrl-C and that unfreezes the Delphi. Delphi then reports error:
Debugger Assertion Failure: "obj"
in ..\win32src\rproxy.cpp at line 663
Package file seems fine to me:
I'm logged on locally as a user in the Admin group.
I can start the application from /Users/primoz/Applications/Embarcadero/PAServer/scratch-dir. No problems there. Run without debugging in Delphi also works. The problem only appears if I try to debug my app.
EDIT: This seems to be a problem with my Delphi installation. I tried the same from my notebook (also running XE2 Update 4) and it works just fine.
EDIT: It seems that this is related to my debug desktop. When I changed debug desktop to be the same as the edit desktop, problems disappeared.
EDIT: This problem only appears if I have 'Thread Status' window visible on the debug desktop. Furthermore, this is related to my Delphi installation - the other computer I tested on works fine with 'Thread Status' window visible.
This problems is related to the Thread Status window. If you experience locking while debugging on OS X, remove Thread Status from the Debug desktop.
Strangely, some XE2 Update 4 installations are working quite fine with Thread Status visible, and some are not.
If you Ctrl-click the app bundle you can choose "show package contents". Now you can browse for the executable itself (not the bundle). If you double click the executable it will run from a terminal window. With a bit of luck a helpful error message appears in the terminal window.
FWIW: my app works fine with 10.7.3 (not sure if I've tried it with PAServer after upgrading from 10.7.2)
As somebody said, the Unity project must be run on devices, but that is a lot of trouble. Is there any way to run a project in iOS's simulator?
Prerequisites:
Mac
XCode
Unity3D for Mac
Guide:
Go to Edit > Player settings > Inspector > iOS tab. Change the Target SDK to Simulator SDK then build the project again.
Open Build Settings and switch platform to iOS.
In the same window set Run XCode as Debug, check Development Build and Script Debugging.
Click Build and Run, choose a directory for iOS builds (for example, create a new directory named Build.iOS)
Build's a long process, take a break.
Unity3D documentation - Building your Unity game to an iOS device for testing.
It was supported until Unity3D 3.3. and iOS 4.??? But the current release 3.4 crashes. See this posting in Unity3D forum.
Anyway I find it easier to run the project in in editor player for debugging and do real testing on the device. Deploying to iPhone via XCode is always annoyingly slow. So I designed my code to distinguish at startup between device and player like
if (Application.platform == RuntimePlatform.IPhonePlayer) {
// do what ever you need
} else ...
Working with the abstract factory design pattern or singletons makes it pretty easy.