Replies: 6 comments 7 replies
-
|
It's just the right place here 👍 Incompatibilities
|
Beta Was this translation helpful? Give feedback.
-
|
Oh I didn't even know there's a dark mode for Windows platforms!? Yeah fairly straightforward for macOS though and luckily I've just found it works in Chrome as well. 🍾 |
Beta Was this translation helpful? Give feedback.
-
|
Yes, there actually is a dark-mode for windows. However, I am not sure to which extend it applies to web-applications. |
Beta Was this translation helpful? Give feedback.
-
|
Hm I think we've actually got unlimited build minutes for public repositories, at least that's what their docs state if I'm not mistaken:
Plus I haven't being charged for builds for public repos yet as far as I can tell from the billing section in my account (there's no "public repos" section) So that'd be great. Uh, also, could you make me an owner of this group as well? I need to set some secrets & upload deployment keys for the App Store. That'd be fab. @OliEfr |
Beta Was this translation helpful? Give feedback.
-
|
You are admin now @welljsjs :) |
Beta Was this translation helpful? Give feedback.
-
|
nw, thanks :-) |
Beta Was this translation helpful? Give feedback.
-
|
It's been quite a while since this was first discussed but I think there is a big potential especially for mobile safari users. A lot of students use for example OPAL on a daily basis on their iPads and I think there are a lot of small annoyances that can be solved :) Apple Developer Account & DistributionSubscriptionOne of the big problems is that there is an apple developer account subscription needed to publish an app on the app store. My suggestion for this is to create an Apple Developer Team and then continuously add new admins [1][3] or transfer the ownership [2] over the years. I currently know a person that would be ready to offer their Subscription for this purpose, so if this is an option it would solve the problem for the next few years. I think it is realistic to find one person every few years and if it does not work out then users can still keep the app installed although they won't be able to update it or install it on new devices. DistributionCreating a Safari Web Extension [4] and converting the current chrome version to a safari extension [5] is relatively simple. Most likely there will be some features that might be broken, but from very short testing the extension seems to work for most things. Though if it is actually planned to go further with this then I'd suggest that we do a testing session to check if most features work as expected and document which don't. In my opinion it would be better to have an extension with some broken or disabled features than none at all. Using a GitHub CI runner seems possible and has been discussed in this thread before but I think it is not strictly necessary. My suggestion would be to delegate the publishing to one person that owns a Mac device for now (MacBook / MacMini / ..., this person does not need a paid subscription to publish) as I think it is not impossible to find someone with such a device. If this approach is not viable the GitHub runner is still an option though more than 4 releases in one month might empty our GitHub free minute capacity, I just think it would be easier to delegate the job to one person first. IncompatibilitiesThere are definitely some compatibility problems and I think there will always be more in the future. I don't think always maintaining full compatibility is a realistic goal as the testing can only be done by a subset of maintainers which might be a blocker for future new features. My suggestion would be to treat the safari extension as a nice to have and just disable features on safari that don't work until someone has the time to fix them. For example shortcuts, search engine superpowers and email notifications are most likely not used as much on mobile (which I think would be the majority of the safari userbase). Therefore I think disabling them if they don't work would be a better solution than demanding full feature parity if it only costs a lot of development time with no real gain. Disabling features based on the used browser seems like a relatively simple thing to do and therefore comes with almost no added complexity. [1] https://developer.apple.com/help/account/manage-your-team/roles/ |
Beta Was this translation helpful? Give feedback.
-
SubscriptionIs there a way to make sure that the versions uploaded to Apple correspond to the code on GitHub? One scenario could be for instance that the extension code in Apple can be viewed without having to install the extension, or that a TUfast core team member has access to the Apple dev portal. Distribution
Agree.
ATM the GitHub CI runner is only used to create the
I dont understand: you want to deligate it to a person with a device, but its not possible to find a person with the device? Do you need a Apple device to upload and publish new versions of the extension? IncompatibilityOkay, agree in principle. One thing: when someone implements an entirely new feature for FF/Chromium, I presume it should be disabled by default for Safari, as it most likely can not be tested and is incompatible. Its goes the other way around as well: if a feature gets developed for Safari, but not tested on FF/Chromium, it should not be enabled for FF/Chromium by default. I don't deem it unrealistic that the latter case happens, as iOS devs can be quite motivated (by my experience - correct me if I misjudge). So it would be nice to have some kind of flag that can easily hide or enable features device-dependent, and is easy to handle for future contributors of the project. Having larger incompatabilities because of that would be a shame.
I do not necessarily see a big downside of the second option. Costs for developing new features is the same, but we save on the device-dependent flag. |
Beta Was this translation helpful? Give feedback.
-
Everyone can have access to the Apple Dev portal but it seems like downloading built binaries from the Apple Dev portal is not possible [2]. Apple offers a service called XCode Cloud [1] which seems to be free for our use case and would allow everyone downloading of the build artifacts. I have not yet found a way to etxract the actual Javascript source files from a built extension but if wanted I can take a look and see if it is possible. But given that the XCode Cloud variant would be basically the same as a CI runner [3] it seems like that could be a big enough source of trust. Ultimately that decision is up to you though and I definitely see the issue with having builds that can't be verified
I meant "not impossible" in the sense of "possbile", sorry for the wording 😅 , but yes you do need to have a device with XCode installed to publish new versions of the extension. It is possible to run a Hackintosh and do everything on a normal PC as well but getting a Hackintosh to work is not trivial and can be a lot of work depending on your hardware. Using the XCode cloud variant it seems like publishing from the GitHub repository would be possible without using an apple device but I have never tried it.
Safari seems to mostly keep compatibility with Chrome but yes I definitely see the issue, I personally do not have that much experience in extension development so I cannot really judge how hard keeping compatibility would be. I will try out some variants of device dependent flags and add them to this discussion later to see how well this could work. I would also try setting up the XCode cloud thing next week to see if that would be a possibility. [1] https://developer.apple.com/xcode-cloud/ |
Beta Was this translation helpful? Give feedback.
-
Having access to the Apple Dev portal would be sufficient for me. I can check what I can do there admin-wise without having an iOS device before the application gets published. It also looks like the rights to publish via XCode Cloud can indirectly be managed via access to the GH repo. Having the CI-pipeline via XCode Cloud and pulling from GH actually seems like the most straightforward thing to do. This needs to be determined by the person actually doing it though. Many thanks for trying it out.
Go ahead if you want. I still don't see the benefit of having a common codebase versus two codebases though (one for FF/Chromium, one for iOS)? The features need to be developed and tested seperately on both platforms in either case, I assume. I would not release a feature to a platform that it hasn't been tested on (unless we can assure that there are virtually no compatibility issues). So far I also was under the impression that the compatibility issues are significant. Maybe @t0mbrn can comment on the compatibility. If the iOS-CI is easy to integrate with our current codebase, it could indeep make sense to keep one codebase only, but I dont know. I see that the Safari integration is moving forward. Thank you very much for all your effort. You both @A-K-O-R-A and @@t0mbrn offered that friends could host TUfast on their accounts, which would be totally fine by me. One thing I would try is to contact a few people at TU Dresden and see if they can provide a reliable funding of 100$/a to finance TUfast on Apple Dev for say at least 5 years. Can the both of you send me an email so that I can keep you in the loop? Find my email at oliver.hausdoerfer.de. |
Beta Was this translation helpful? Give feedback.
-
XCode CloudI tried the XCode cloud integration and it seems to work when just putting the transpiled I did not yet get to trying out the previously talked about OS dependent flags. I do currently have a running iOS&MacOS extension build and want to try out all of the already implemented features to check if there compatibility issues. The only problem I have found so far is a slight discrepancy in the behavior of the The layout in the settings also looks bad on mobile devices but I don't think that has something to do with Safari. The small popup also does not fit on a mobile screen but I don't think this is a major issue and can be fixed relatively easily. [1] https://developer.apple.com/documentation/xcode/writing-custom-build-scripts After reading some more in the apple developer documentation I have found out that the Team Owner has to be the person that pays the subscription. This means that simply transferring the team Ownership is not an option and instead it would be necessary to transfer the single App from one Team to the next [2][3]. This seems relatively straight forward though so I think the plan that I suggested previously would still work.
This would of course be the best solution, I'll send you an eamil from my university account :) [2] https://developer.apple.com/help/app-store-connect/transfer-an-app/overview-of-app-transfer |
Beta Was this translation helpful? Give feedback.
-
I managed to come up with some points I found relevant for the development for Safari/macOS so I've created a list as some sort of rough plan to structure my ideas and to collect some helpful content while gathering resources.
I'll add to this list as we go so feel free to post your thoughts/comment.
Edit: Sorry never been using GH discussions so far... is the the right place or should I move this over to issues? @OliEfr
TO-DO / Safari Incompatibilities
To-Do List (top to bottom)
Incompatibilities
This is a short but interesting read about building a cross-browser extension (funny enough they don't mention Safari but hey, don't blame Mozilla).
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Build_a_cross_browser_extension
This is a collection of tables to show browser support for JS APIs, very useful and seems to be kept up to date:
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Browser_support_for_JavaScript_APIs
...and this table shows browser compatibility for the
manifest.jsonfile, again very handy:https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Browser_compatibility_for_manifest.json
include_globsThe "content_scripts" key attaches content scripts to documents based on URL matching: if the document's URL matches the specification in the key, then the script will be attached.
Since matches is the only mandatory key, the other three keys are used to limit further the URLs that match. To match the key as a whole, a URL must:
include_globs: Array An array of strings containing wildcards. See Matching URL patterns below.persistentThe only occasion to keep a background script persistently active is if the extension uses chrome.webRequest API to block or modify network requests. The webRequest API is incompatible with non-persistent background pages.
declarativeContentUse the chrome.declarativeContent API to take actions depending on the content of a page, without requiring permission to read the page's content.
system.cpuUse the system.cpu API to query CPU metadata.
https://developer.chrome.com/docs/extensions/reference/system_cpu/
Beta Was this translation helpful? Give feedback.
All reactions