It still works with xbuild.
Ive sent you an email with a link.
Thanks,
John
thanx, Iāll have a look later today.
Is there any chance this can be looked into ?
Its this problem from the logs
*** Terminating app due to uncaught exception āNSInternalInconsistencyExceptionā, reason: āUnable to instantiate the UIApplication subclass instance. No class named SPApplication is loaded.ā
*** First throw call stack:
(0x1c713c81 0x1ba49a7f 0x1c65e7d7 0x1cff6465 0x354ad237 0x354acf27 0x1c4441bf 0x1c44627f 0x1cf74345 0x232673c9 0x2326720d 0x232676ff 0x1d10a5eb 0x1c27caa3)
It stopped working after the switch to ebuild.
Cheers,
John
I pretty much stand by what I said before:
Thats disappointing, Itās not like it never worked.
I was reading this on stackoverflow
and something is different that before but I dont know what.
Right, but its not I can debug every single build failure for you. That just doesnāt scale.
These are complicated tool chains, and Elements gives you detailed logs of what itās doing that allow you to self-diagnose whatās going on. This icludes the exact linker commands used, what Apple tools we run to process tour additional assetts, etc. In addition, you can look into your .app and .ipa bundles yourself to see whats in there, use tools like class-dump to see if the types are there, check your Info.plists, or whatever might be necessary to find what is wrong.
The WatchKit toolchain is a total pain the the butt form everyone, no matter if they are using Elements or Xcode, and I realize itās often terribly difficult to figure out whats going wrong (I have yet to see a successful Watch app running, myself, even with Xcode), but itās not something I can help with, as I know doodly squat about watchOS development in general, or youāre concrete issue in particular. Like, I dint even know what SPApplication is supposed to be. Itād not a watchOS framework class, from the sounds of it, and Google has zero hits on it.
Sorry :(.
A good starting point would be to try and see what is different.
I couldnāt see any significant differences in the info.plist files between xbuild and ebuild.
I did a class dump on the extension file. Im not really sure what Im meant to be looking for ?
I noticed that at the top of the file for the xbuild output it has these comments
//
// File: iSailedWatchOSExtension
// UUID: D9A069EB-4A71-354E-B0D6-F6C6E85899BB
//
// Arch: armv7k
// Source version: 0.0.0.0.0
//
// Objective-C Garbage Collection: Unsupported
//
// Run path: @executable_path
// =
// Run path: @executable_path/Frameworks
// = /Frameworks
// Run path: @executable_path/ā¦/ā¦/Frameworks
// = /Frameworks
//
Whereas the ebuild one has
//
// File: iSailedWatchOSExtension
// UUID: FC8878F8-6D4C-3FB3-A939-6BE0D5D0DB57
//
// Arch: armv7k
// Source version: 0.0.0.0.0
//
// Objective-C Garbage Collection: Unsupported
//
// Run path: @executable_path/Frameworks
// = /Frameworks
// Run path: @executable_path/ā¦/ā¦/Frameworks
// = /Frameworks
//
Why would the ebuild one have this missing ?
Run path: @executable_path
// =
Curious. Can you try putting @executable_path into the Linker @rpath setting and see if that (a) fixes the class-dump output, and/or (b) fixes your problem?
āmarc
It fixes (a)
It still crashes when I launch but the console has stopped displaying watch output so I will tell you what the reason is when it decides to work again.
In the extension and watch app projects is settings meant to display @rpath ? It currently doesnt so I edited the project file myself
ok, good. that means, as i expected, that setting isnāt necessaryā¦
I did a class-dump on the watch app ie the one that contains the Extension as a reference
in the xbuild I get this
//
// File: iSailedWatchOS
// UUID: 6A749300-107C-37F8-A245-5D5C4CE8AED6
//
// Arch: armv7k
// Source version: 884.0.0.0.0
//
// Objective-C Garbage Collection: Unsupported
//
but the ebuild one has this
//
// File: iSailedWatchOS
// UUID: 6A8BD7C8-67AB-3EA8-9A08-926E097D1A58
//
// Arch: arm64_32
// Source version: 1021.2.10.0.0
//
// Objective-C Garbage Collection: Unsupported
//
That doesnt appear to be what the settings is saying
can i see the full build log? can you try setting armv7k explicitly? (that said, watchOS now does support 64 and 32 bit, so it could be youāre just looking at the wrong slice (and maybe the default shown in fire is off. iāll check)
buildlog.txt.zip (21.6 KB)
It seems to ignore if I explicitly set the value
D: Target-specific Settings, after prepare
D: - <Architecture = armv7k [Target: Toffee-watchOS]>
D: - <Architecture-Device = armv7k [Target: Toffee-watchOS]>
D: - <Architecture-Simulator = i386 [Target: Toffee-watchOS]>
D: - <BinaryName = iSailedWatchOSExtension [Target: Toffee-watchOS]>
...
-> Task RemObjects.EBuild.Elements.ElementsCompile started for iSailedWatchOS Extension.
Compiling target 'Toffee-watchOS', Device
-> Target Toffee-watchOS started compiling for Device.
...
-> Task Merge started for iSailedWatchOS Extension, Toffee-watchOS.
D: MergedLinkerOutput
D: - <MergedLinkerOutput-Device: /Users/JohnMoshakis/Library/Application Support/RemObjects Software/EBuild/Obj/iSailedWatchOS Extension-B198A695BC9A06EB6165AB9C2407EA34D63ED90B/Debug/Toffee-watchOS/Device/armv7k/iSailedWatchOSExtension [Target: Toffee-watchOS]>
D: - <MergedLinkerOutput-Simulator: /Users/JohnMoshakis/Library/Application Support/RemObjects Software/EBuild/Obj/iSailedWatchOS Extension-B198A695BC9A06EB6165AB9C2407EA34D63ED90B/Debug/Toffee-watchOS/Simulator/i386/iSailedWatchOSExtension [Target: Toffee-watchOS]>
<- Task Merge finished for iSailedWatchOS Extension, Toffee-watchOS, took 0.0074s (0.0077s).
...
all looks correct to men, its building armv7k, not arm64ā¦
Iāve gone ahead an build my own watch app:
Floorshow:WatchKitAppExtension.appex mh+ $ class-dump WatchKitAppExtension
...
//
// File: WatchKitAppExtension
// UUID: 5CC842B5-1A10-348A-AC6B-8885B8D0576B
//
// Arch: armv7k
// Source version: 0.0.0.0.0
//
what am I missing?
Itās the other one. You know there are 2 projects the watch os app and the extension. I did a class-dump on the watch app
FWIW, this project, just created from scratch from the templates, builds fine, installs on my phone, the watchOS app shows in the Apple Watch application and from there I can install it on my Apple Watch w/o errors:
iOSAppWithWatchApp.zip (936.7 KB)
We donāt build the watch app itself. itās a pre-made executable Apple provides that we just copy. I donāt see how that could differ between xbuild and EBuild, but it might be worth checking the log to see where itās copied from. Not sure if the old xbuild based tool chain exposed that info, but EBuild does:
-> Task Merge started for iSailedWatchOS, Toffee-watchOS.
D: MergedLinkerOutput
D: - <MergedLinkerOutput-Device: /Applications/Xcode.app/Contents/Developer/Platforms/WatchOS.platform/Developer/SDKs/WatchOS5.2.sdk/Library/Application Support/WatchKit/WK [Target: Toffee-watchOS]>
D: - <MergedLinkerOutput-Simulator: /Applications/Xcode.app/Contents/Developer/Platforms/WatchSimulator.platform/Developer/SDKs/WatchSimulator5.2.sdk/Library/Application Support/WatchKit/WK [Target: Toffee-watchOS]>
<- Task Merge finished for iSailedWatchOS, Toffee-watchOS, took 0.0074s (0.0077s).
when I run file on my version of that I get, as expected
Floorshow:~ mh+ $ file "/Users/mh/Applications/Xcode-10.2.app/Contents/Developer/Platforms/WatchOS.platform/Developer/SDKs/WatchOS5.2.sdk/Library/Application Support/WatchKit/WK"
/Users/mh/Applications/Xcode-10.2.app/Contents/Developer/Platforms/WatchOS.platform/Developer/SDKs/WatchOS5.2.sdk/Library/Application Support/WatchKit/WK: Mach-O universal binary with 2 architectures: [arm64_32_v8:Mach-O executable arm64_32_v8] [arm_v7k:Mach-O executable arm_v7k]
/Users/mh/Applications/Xcode-10.2.app/Contents/Developer/Platforms/WatchOS.platform/Developer/SDKs/WatchOS5.2.sdk/Library/Application Support/WatchKit/WK (for architecture arm64_32): Mach-O executable arm64_32_v8
/Users/mh/Applications/Xcode-10.2.app/Contents/Developer/Platforms/WatchOS.platform/Developer/SDKs/WatchOS5.2.sdk/Library/Application Support/WatchKit/WK (for architecture armv7k): Mach-O executable arm_v7k
Floorshow:~ mh+ $
so thatās correct. class-dump only seems to see the arm64_32 slice (Iām guest it just dumps the first slice):
Floorshow:~ mh+ $ class-dump "/Users/mh/Applications/Xcode-10.2.app/Contents/Developer/Platforms/WatchOS.platform/Developer/SDKs/WatchOS5.2.sdk/Library/Application Support/WatchKit/WK"
2019-04-22 09:03:17.103 class-dump[88260:8618369] Unknown load command: 0x00000030
//
// Generated by class-dump 3.5 (64 bit).
//
// class-dump is Copyright (C) 1997-1998, 2000-2001, 2004-2013 by Steve Nygard.
//
#pragma mark -
//
// File: /Users/mh/Applications/Xcode-10.2.app/Contents/Developer/Platforms/WatchOS.platform/Developer/SDKs/WatchOS.sdk/Library/Application Support/WatchKit/WK
// UUID: 6A8BD7C8-67AB-3EA8-9A08-926E097D1A58
//
// Arch: arm64_32
// Source version: 1021.2.10.0.0
//
// Objective-C Garbage Collection: Unsupported
//
so that matches what you see, but it would not indicate a problem (although Iād be curious to see what xbuild gives you a different result ā sure youāre building your xciild app against the same SDK version)?
And it runs ? Iāll try again later today using a new template and see how far I get.
Thanks for the explanation.
Iāve been comparing against the app file I sent you a while back, so it would be a long time ago.
That would make sense ten, youāve buld that against 4.x or lower, probably, which did not support 64bit.