Apple sunsetting Rosetta2 in 2027 → this effects Web-Framework 1

Targets Web
1

Apple just announced that they’re removing Rosetta2 from future MacOS Versions starting fall 2027.

Rosetta2 is the layer that makes Intel-x86-application run on they Apple-Silicon architecture.

Xojo 2019R3 is the last release with WebFramework1. I believe that some of you still use it. It’s not Apple-Silicon-native and it runs only through Rosetta2 on modern Macs. As soon as Rosetta2 is being removed, this Xojo release (and every release prior) won’t work anymore.

@Geoff_Perlman how likely is it, that you can/will bring a Xojo2019R3 LTS Version, which runs natively on AppleSilicon?

2 Likes
2

I think it would be better that we find ways to help those using Web 1 to transition to Web 2 given that we haven’t been updating Web 1 in years.

2 Likes
3

Keep your Mac frozen at Tahoe until you upgrade your system to Web2.

1 Like
4

Yes, please.

How about getting current Xojo to open a Web 1 sample project and just run it?

You know, by adding a few things we had in Web 1 to Web 2 to make it compatible.

4 Likes
5

This would be very beneficial. Web2 has now nearly feature parity.

Ping me, when we can assist here with insights. Our Web1 projects has around 1.400 different components (classes, nested container controls, and also around 50 custom controls (which we would rewrite manually for sure)).

6

Didn’t you want to rewrite your Web1 project in a different language because you didn’t want to bore your developers?

7

We‘re on it. Still, reaching feature-parity of an application which was under active development for 10 years by 3-12 devs, takes a lot of time.

So increasing the longevity of the legacy product is much appreciated.

1 Like
8

Would you say that the effort to move to web 2 is primarily the layouts?

9

It doesn’t help that Web 2 is also API 2. That means that nearly every line of code needs to be touched as well.

The webSDK was completely updated and redesigned so custom controls have to be recoded.

Note: I understand that I’m partially to blame for all this. It was my design & implementation that lead to these incompatibilities.

8 Likes
10

It’s one of the main problems, yes.

In our particular case, we already tried to use as much API2 as possible. Also, I guess this is not avoidable.

Mostly, yes, but we already made some good wrappers, which keep the functionality and lower the urgency.

Coding-Tasks tasks can also be supported by AI, transforming the UI unfortunately not.

¯\_(ツ)_/¯ It is what it is.

11

using an AI and a good prompt would eventually convert web1 to web2 project not so difficult ?

1 Like
12

What might help is if Xojo produced a set of modules / classes for API v1 that mimicked API v2. Users could drop these into their current project and start converting their code to the API v2 syntax while still being able to use the v1 API version of Xojo. At the point the user wanted to use their project in a recent version of Xojo they could just delete these modules / classes.

1 Like
13

Why would you need this? Projects can currently mix API1 and API2 with no issue.

14

My mistake. I thought API v2 was introduced after the last version of Web v1.

However, would it not make the transition easier if as much as the API v1 syntax could be made available to Web v2 projects somehow?

15

Sorry - I think I’m mixing things up. The core language API2 and API1 elements can be combined, and you can (somewhat) mix API1/2 UI elements, as long as they live in separate windows. This is perhaps different for Web; I’m a desktop developer…

16

Yeah, you can’t do this with web 1/web 2 UI. The original web framework was the first time the Xojo IDE had the concept of a “prefix” of Web to designate that the controls were not controls for desktop projects. When Web 2 was introduced, there was no easy way to have two different “WebButton” controls at the same time without a new prefix and we really wanted to stick with “Web”.

3 Likes
17

So, what could a plan look like?

18

Don’t forget that if push comes to shove you can run Windows 11 ARM in a parallels VM and run any Intel version of Xojo in it to continue your development there.

It’s certainly not optimal but with their Coherence mode along with careful drive/folder mapping, it might make the process mostly transparent.

Again, if push comes to shove

19

No.

20

I’m curious, looking back, why was the three-letter “Web” string so critical to reuse? Considering all that was abandoned, do you think an alternative like “www” or “net” would have been a better decision in hindsight?