Let --noinstall on an installed app work with just a --bundle_id rather than --bundle

[xster]

Context: https://github.com/flutter/flutter/issues/60657#issuecomment-686359223

To describe the context a bit more, the .app file is more of a wrapper shell than the source of truth for the execution for Flutter. In other words, for the Flutter developer, the content of the .app might never change for the debug session. All the debugging and development modifications are done by connecting to the unchanging .app and injecting JIT code and reloading. In this case, the .app file's location the host doesn't matter too much and sometimes, for complex apps with a big build infra, the Flutter developer might never have the means to actually build the .app from his local machine. The Flutter developer might just be given a phone with an app already installed and debugs by attaching and injecting more JIT code without ever seeing the .app file.

[gabebear]

Launching from bundleID would likely be possible to implement, but is not trivial. Someone would need to find a way to get the remote path from the bundleID somehow.

From my understanding, this option would help 100% Dart Flutter apps but would not be useful for developers who use packages with native components; Correct? A better option might be if Flutter switched to using the --app_deltas option. Using deltas would:

• stop re-sending the Flutter default app over on every launch (re-launches are extremely fast)
• update the signed iOS binary if changed:
  • updates the default app if needed
  • allows for native plugins to be used
• be more modern:
  • it makes even fresh installs faster. Using --app_deltas to install a completely fresh app is slightly faster than the legacy way.
  • it's the code-path modern Xcode always uses(less likely to be removed in the future)

The biggest downside to using --app_deltas is that Flutter would need to make a temp folder per project that is used to keep track of the differences between app versions.

[xster]

I agree on --app_deltas. It's something we generally likely want to do. For bundle id / .app, it's mostly orthogonal. It would help the Flutter case, but I don't know if it's unique. I think it would generally help situations where the developer doesn't have access to the .app or the .xcodeproj but want to enter lldb for an app that's already on the device.

[gabebear]

The technical issue with using the bundleID is that we use the structure of the files in the app's bundle to figure out the path to the the executable binary. To run the app we need to know the path to the binary file. http://lldb.llvm.org/use/remote.html#install-and-run-by-specifying-a-remote-install-path

I don't know how to lookup the path to the binary for a given bundleID. We do have methods for finding whether a given bundID has an associated app(only true/false), so there is a good chance there is some undocumented method that would allow this, but it also might be impossible.

I don't know who would be willing to take on this work since there are good alternative approaches.

[gabebear]

It does look like this is very doable(AMDeviceLookupApplications is used to retrieve the path of the binary on the device).

We would gladly accept a PR!

[ivanhernandez13]

I was wondering why this wasn't already possible so decided to take a very brief look last night.

Jotting down some quick notes:

• As Gabe mentioned, AMDeviceLookupApplications can lookup app bundles installed on a device.
• The bundle ID to app bundle path lookup is possible with the existing copy_device_app_url() function.
• We can find the path to the app bundle on the remote device but I think lldb might need the path to the local app bundle in order to load the process into memory before it can launch the remote process.

It might be possible for lldb to load the remote process over the connection but did not look into it. Assuming this can be done though this will need some minor argument validation adjustments:

• Currently ios-deploy checks for valid argument combination (e.g. do we have an app bundle path) before any work has been done.
• Performing a bundle ID to app bundle path lookup requires we connect to the device so we need to find the device first.

[Am not actively working on this, the quick proof of concept attempt is uploaded here.]