Launching watchapps from other watchapps

Watchapp/Face Developers Corner
1

As part of my larger plan for a multiplayer ecosystem, it would be awesome to have the ability to launch one app from another, e.g.

  • User 1 is in a game
  • User 2 is in the hub world
  • User 1 invites User 2 to play
  • User 2 accepts the invite, hub world app closes, game app launches

Is this app-launches-app something that is possible to implement? Or is it something that’s already possible that I’ve overlooked?

3 Likes
2

It would only work on Android, but can’t Pebblekit Android open apps for you? Or is that only in V1?

2 Likes
3

Yes you’re right i think Flynn, PK Android should be able do that.

But to provide more information and limitations:

  • Ideally any solution would also work on iOS because, well, I’m on iOS :sweat_smile: I do have a Pixel for development since most folks are on android
  • Creating a companion app would be far beyond the scope for these projects, unfortunately, so if it’s a phone side implementation it would need to be in PKJS
1 Like
4

I could see two useful paths for an API to allow apps to launch other apps.

  1. A developer wanting to create an ecosystem of apps (like Link) to create large experiences within the confines of the strict memory limit (a chat room like app launches a mini game app). These apps could register UUIDs to know what should be allowed to launch them (if that’s a concern)
  2. A system-level detail like Quick Launch where you can assign “Preferred Apps”, saying “Timer+ is my preferred Timer app”. Then apps like Claude, Bobby, or even simply voice assistant apps (or a system wide one) could know that when I say “start a timer for 5 minutes”, it just has to call launch_user_preferred_app(TIMER, 5) and Timer+ could implement the AppLaunchReason API for some sort of APP_LAUNCH_OTHER_APP to start the timer right away.
2 Likes
5

Playing devil’s advocate for a bit, launching other apps without user intervention seems quite useful… until it isn’t. Example, user A installs a neat background application. Unknown to user A, that background application starts another application that causes havoc. Could be intentional, could be just bad coding that drains user A’s battery. Either way, without guard rails, there is potential for malicious behavior. Putting that “check” in the SDK means that someone could code around it. Putting that functionality into the System means that is one more activity that happens on every such call, possibly making battery charge worse.

Again, nothing against the idea but there are definitely trade offs.

1 Like
6

Just as a response back to the concerns:

  1. Today actual background apps are restricted to only one allowed by the system and the user has to explicitly enable it as a background app in settings. It’s also very restrictive what that app can do
  2. An app can use the WakeUp API for this where it periodically wakes up and launches an app for sure. This raises that it should probably be up to user discretion to allow the app to perform this action, similar to allowing health or timeline (?) access
  3. The user still has to have both App A and App B installed. If App B isn’t installed the function would presumably no-op or return an error for the developer
  4. There’s no ask for interaction between the two apps, just a one way data flow that the consuming app may or doesn’t have to consume, so once App B is open App A is dead unless the developer created an infinite loop. I think this raises a good point that if implemented there should be some sort of rate limiting by the system to prevent misbehavior
  5. I think it’s fine the OS would handle this. It’d just have to enforce the UUID handshake if that’s something that is of a concern for preventing misuse. Someone could remove that and distribute a third party OS but that’s not a concern of PebbleOS users.

Not that any of your concerns aren’t valid, just noting that what I think are already protections in place and current OS behavior that wouldn’t necessarily cause an issue + some notes that these considerations could require more thought on implementation if they are concerns (if anyone even wants to implement this)

2 Likes
7

All good points. Currently, Pebble seems to be operating “under the radar”. There’s interest and it may grow. This might be a non-issue and I’m fine with that. I’m also old enough to remember the times tech said “Oh… it can’t happen like that!” and then it did. I don’t worry about known scenarios as much as unknown scenarios. Open a hole and someone’s going to manipulate it, if only just because they can. The safest approach would be to not open a hole. But, holes also permit innovation in ways most wouldn’t think about. Such as the game developer that simply wants to communicate with other players on the Pebble platform, peer to peer without an intervening server (as I understand it). Very innovative and could open up other possibilities of other group activities where sharing information among the groups would be desired. Perhaps another notification type might answer that. Perhaps not. But I do see the possibilities… and the dangers.

1 Like