Fire: Building solution containing watchkit app

(JohnMoshakis) #121

It still works with xbuild.

Ive sent you an email with a link.

Thanks,
John

(marc hoffman) #122

thanx, I’ll have a look later today.

(JohnMoshakis) #123

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

(marc hoffman) #124

I pretty much stand by what I said before:

(JohnMoshakis) #125

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.

(marc hoffman) #126

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.

(JohnMoshakis) #127

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
// =

(marc hoffman) #128

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

(JohnMoshakis) #129

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

(marc hoffman) #130

ok, good. that means, as i expected, that setting isn’t necessary…

(JohnMoshakis) #131

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

(marc hoffman) #132

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)

(JohnMoshakis) #133

buildlog.txt.zip (21.6 KB)
It seems to ignore if I explicitly set the value

(marc hoffman) #134
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?

(JohnMoshakis) #135

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

(marc hoffman) #136

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)

(marc hoffman) #137

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)?

(JohnMoshakis) #138

And it runs ? I’ll try again later today using a new template and see how far I get.

(JohnMoshakis) #139

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.

(marc hoffman) #140

That would make sense ten, you’ve buld that against 4.x or lower, probably, which did not support 64bit.