Watchkit app hangs (spins forever) - activePlugInForIdentifier: returned nil for application

Hey all,


Setup:

  • Xcode 6.3.2
  • iOS/WatchKit SDK 8.3


What Works:

  • App groups are configured and tested to be working.
  • Local development builds with development provisioning profiles work.
    • I can build & debug to my Apple Watch hardware.
    • Simulator also works (not that this matters).


Now, enter ad hoc distributions via Crashlytic using our CI (Jenkins) environment. The application is distributed fine, and installs on device fine.


But....

Issue:

  • Launching the application once installed on the Watch (via Crashlytics) results in a spinner that hangs forvever.
  • Eventually (after about a minute) the app crashes.
  • I've stripped the application down to a single controller with a button (no networking or heavy async stuff going on).


To re-iterate - my local development builds to device work perfectly fine.


Any ideas!? Is there a way to get the logs for what is going on with the watch?

Accepted Reply

Fixed!


For anyone interested, we accidently had left a ARCHS='armv7' argument in our xcodebuild script.


Hope this helps.

Replies

Update:


I've stripped down the application to a single page with a label. No assets. No network requests.


Again, it launches fine with local builds and spins forever and eventually crashes with enterprise builds.


I checked out the logs and sure enough there is an error:


Hub connection error Error Domain=NSCocoaErrorDomain Code=4097 "The operation couldn’t be completed. (Cocoa error 4097.)" (connection to service named com.***.watchkitextension)

<Notice>: (Error) WatchKit: <SPCompanionAppServer.m __51-[SPCompanionAppServer sendToRemoteInterface:call:]_block_invoke519:914> activePlugInForIdentifier: returned nil for application com.***.watchkitapp


I've googled the error code quite a bit but nothing concrete has surfaced.


Anyone @ Apple have any idea of what is going on?

The plot thickens!


We re-genereated all of our certificates to ensure they were swift compliant.


Now we have a new error:


Program specified by service does not contain one of the requested architectures: 16777228:arm64


We have triple checked that both the parent app, extension and all linked frames are arm64 compliant (via "Archictures -> Standard Architectures").


Any ideas?

Hi terryworona,

Make sure that arm64 also appears in the "Valid Architectures" for your WatchKit Extension.

Thanks Justin,


The watchkit extension does indeed have arm64 set as a valid architecture (+ armv7 and armv7s), along with the parent application and all linked frameworks.


Again, the sequences of events from the console logs on launch (*** is our bundle id):


6/18/15, 10:47:28 PM pkd[4784]: assigning plug-in ***(1.0) to plugin sandbox
6/18/15, 10:47:28 PM pkd[4784]: enabling pid=4783 for plug-in ***(1.0) /private/var/mobile/Containers/Bundle/Application/***.app/PlugIns/***.appex
6/18/15, 10:47:28 PM com.apple.xpc.launchd[1]: Program specified by service does not contain one of the requested architectures: 16777228:arm64
6/18/15, 10:47:28 PM companionappd[4783]: plugin *** interrupted
6/18/15, 10:47:28 PM companionappd[4783]: Hub connection error Error Domain=NSCocoaErrorDomain Code=4097 "The operation couldn’t be completed. (Cocoa error 4097.)" (connection to service named ***.watchkitextension) UserInfo=0x15deac160 {NSDebugDescription=connection to service named ***.watchkitextension}
6/18/15, 10:47:28 PM companionappd[4783]: (Warn ) WatchKit: <SPApplicationManager.m __83-[SPApplicationManager getOrBeginActivePlugInForApplication:setupBlock:completion:]_block_invoke_2321:496> Unable to start plugin ***.watchkitextension 0x15dea0480 with identifier ***.watchkitapp (Error Domain=NSCocoaErrorDomain Code=4097 "The operation couldn’t be completed. (Cocoa error 4097.)" (connection to service named ***.watchkitextension) UserInfo=0x15deac160 {NSDebugDescription=connection to service named ***.watchkitextension})
6/18/15, 10:47:28 PM companionappd[4783]: (Error) WatchKit: <SPCompanionAppServer.m __51-[SPCompanionAppServer sendToRemoteInterface:call:]_block_invoke519:914> activePlugInForIdentifier: returned nil for application ***.watchkitapp


This repeats on a loop for a minute or so until it crashes:


Exception Type:  EXC_CRASH (SIGABRT)
Exception Subtype: LAUNCH_HANG
Exception Message: The extension took too much time to initialize
Highlighted Thread:  0


Any other suggestions would be much appreciated!


We are completely out of ideas as there isn't much information on the subject (ie. stack overflow, etc).

Fixed!


For anyone interested, we accidently had left a ARCHS='armv7' argument in our xcodebuild script.


Hope this helps.

Genius! Thanks for this! Given this tip (arm64 under Valid Architectures in list for watchkit app and watch app) and a post from another forum (below), I finally got my iOS/WatchOS app working again on Xcode 7 beta 3 / iOS 9 beta 3 / Watch OS 2 beta 3!


Other useful post:

dhash

Jul 16, 2015 7:26 AM(in response to shagans)

I have found a solution to this:

1. Run app on device from xcode. Wait for loading daisy on watch

2. Force quit app. (Hold friends button until power options displays, then hold friends button again until app closes.)

3. Stop debugging on xcode

4. exit xcode (do not reboot/restart xcode)

5. run app on watch. It should run now.

6. if this does not work start from step 1 again.

Cannot believe that sequence of steps worked. I never, ever would've thought to do that. Thanks for the post

I was just playing around and had no CI, so the build-settings regarding ARCHS were still default as after adding the target.


Actually, the problem on my side seems to have been, that the watchOS-Extension-target had a higher Deployment-Target-version set (3.2), as the Watch had installed (3.1.2). After changing only this setting, the app started.


The Xcode-version used was 8.3.2 (8E2002). Interestingly neither Xcode warned about this, nor did I see any console-output regarding this. The previous output that brought me here (title) didn't appear anymore. You should get your settings straight, but this is a very simple automatic pre-compile-check and is done for the other targets as well.


All the uninstall, reboot, restart stuff seems to me like: "I don't know, what to do anymore and I hope some magic will fix it." People shouldn't call it a "solution", though. A solution requires understanding of the root-cause and a reasonable change to resolve it.


Regards

I'm having the same issue. Any resolution to this? Seems random. Was working yesterday only to stop working today.