Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

iOS Support #106

Open
Almouro opened this issue May 11, 2023 · 13 comments
Open

iOS Support #106

Almouro opened this issue May 11, 2023 · 13 comments
Labels
enhancement New feature or request

Comments

@Almouro
Copy link
Member

Almouro commented May 11, 2023

iOS support isn't a priority at the moment, since on average iOS devices performance is much better (and usually that translates to apps having less performance issues).

However it is still something we want to search into and implement at some point, so if you'd like to have iOS support, feel free to show it by adding a 👍 emoji to this issue.

@developerdanx
Copy link

developerdanx commented May 12, 2023

How can we help with iOS support?

@Almouro
Copy link
Member Author

Almouro commented May 15, 2023

Thanks for asking @developerdanx!

On iOS, we haven't investigated much a technical solution yet.

For the performance measuring part, I think one possibility would be to use xctrace (previously XCode instruments) to generate a trace file, and then manage to parse it to get an array of measures out of it

If you'd like to try your hand at a POC, I'd be happy to help out!

@developerdanx
Copy link

Yes this is feasible I think. I'll try something out and share the results 😁

@Almouro Almouro added the enhancement New feature or request label May 16, 2023
@GuillaumeEgret
Copy link
Contributor

GuillaumeEgret commented Jun 12, 2023

Hi ! Quick update, we are also going to try to develop a POC for iOS in the next few days with @Almouro

@Almouro
Copy link
Member Author

Almouro commented Jun 29, 2023

We've deployed the (crude) POC here https://github.com/bamlab/flashlight/tree/main/packages/ios-poc

We'll work to make it easier to use in the coming weeks with @GuillaumeEgret 🤞

@Almouro
Copy link
Member Author

Almouro commented Sep 14, 2023

Still in progress, but @GuillaumeEgret managed to have a POC of CPU measures per thread when running a Maestro test
It's already running in the CI on this repo https://github.com/bamlab/flashlight/blob/main/.github/workflows/ios_e2e.sh

Here's an example report: https://65031abea84fdb098fb48ce4--flashlight-open-source-reports.netlify.app/report.html

Next is:

  • unify API with flashlight test on Android
  • consider live measures with flashlight measure
  • run it on AWS for complete Lighthouse for iOS apps

@JuanRdBO
Copy link

Hey guys! Is this still ongoing? I'd love to test iOS devices as well

@alaz-aura
Copy link

+1 to see if this iOS support is still in development

@anton-patrushev
Copy link

hey everyone 👋
do you have any updates for iOS support?

cc: @Almouro

@samholmes
Copy link

+1 for this too.

How can I help contribute to this effort? I'd like to know what are the technical challenges: is it building the perf app in iOS, or is it installing it on a device (idb hurdle), or something else?

@Almouro
Copy link
Member Author

Almouro commented Sep 6, 2024

Sorry it took so long for me to answer this, it's a good idea to sum up a bit where we're at at the moment!

Sadly, things are not as easy as on Android, where we can just openly read values from system files.

There are 3 elements that are part of the Flashlight philosophy for Android which are tricky to get on iOS:

  • live measures with flashlight measure
  • thread by thread measures
  • blackbox measures (as in: no in-app setup required, can work on production apps)

We have a few approaches that we've tried but are not entirely satisfied with, (and it's also a challenge to dedicate resources to this on our side.)

1st approach: Instruments CLI

❌ Live measures
✅ Thread by thread measures
✅ Blackbox measures

On iOS, Instruments is the usual tool used for performance measures. It's in my opinion very adequate and technically ticks all the boxes above.
However, it's not necessarily easy to use and doesn't offer an easy comparison view.

Instruments however offers a CLI that we can use. Sadly, that CLI doesn't offer live measures. It's also not super easy to use, but @GuillaumeEgret did a fantastic job researching and parsing the output.

It's not totally done still, and there's still this PR open to get it merged that we need to get back to.

2nd approach: using py-ios-device

✅ Live measures
❌ No thread by thread measures
✅ Blackbox measures

Several people have already tried to do something similar and capture live measures with their own tools. One such tool is https://github.com/YueChen-C/py-ios-device. Essentially those tools can behave just like Instruments would and talk with the app to get the same data.
The way to create such a tool is basically by reverse engineering Instruments and it's not an easy task by any mean. The protocols used by Instruments to communicate with the app is reaaaally not straightforward 😅

Unfortunately thread by thread measures seem quite hard to achieve with such a tool.

We do have a POC here which should be working, although we haven't tested it in a while 😬

3rd approach: create a plugin to install in the measured app

✅ Live measures
✅ No thread by thread measures
❌ Blackbox measures

We haven't explored this approach a lot, but coming back to it might be a good idea.
The idea would be to have something similar to https://github.com/bamlab/react-native-flipper-performance-monitor

We install an SDK in your iOS app, which can get all relevant data, and communicate that data to Flashlight via websocket. We haven't explored yet what is possible, but it seems we could get out of the box live measures and thread CPU measures.

It generally seems simpler to implement and easier to maintain, however we lose the blackbox aspect:

  • we need to install an SDK in the app, which shouldn't be published with the app to the appstore

On the other hand, it's much simpler to have quick feedback on what we implement, even if it's in dev mode

In general, my current point of view is I feel like maybe we should reconsider the 3rd approach to see what we can do!

Feel free to jump in the conversation and share your point of view, or just add an emoji 1️⃣, 2️⃣, 3️⃣ to notify which option you'd rather have.
If you'd like to try your hand at implementing one option, or have another idea in mind, let me know and I can help out!

I'll also try to restart that conversation with the RN community as well before the end of the month

@bvoq
Copy link

bvoq commented Sep 30, 2024

Maybe 1️⃣ together with a video recording?
We use it mostly with maestro tests at the moment.

@Almouro Almouro pinned this issue Oct 3, 2024
@MalcolmTomisin
Copy link
Contributor

Previously, I wouldn’t have chosen 1️⃣ as my go-to, as I loved using Flashlight for live measurements. Recently, however, I’ve started using Flashlight to create performance reports, and it’s been working well for me. I’m also leaning towards 1️⃣ now because it provides thread-by-thread and black-box measurements, which offer a more streamlined developer experience when debugging performance issues

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

9 participants