macOS 10.15 Catalina on Unsupported Macs

[Starplayr]

This ridiculous overly-complex "libs linking to libs" thing is one of the main reasons why Swift is so bad. At this point, the only thing Swift is good for are extremely high-level programs, that do nothing more than interface with a REST API (which is EXACTLY what this whole "SwiftUI" stuff is geared towards). I really think using Objective-C would have been a MUCH better route to go for writing a program like this. All Swift is is an overly complex link down to Objective-C/Foundation libs, while trying to "hide" the Objective-C part from the developer. On top of that, it also utilizes a very confusing and honestly extremely counter intuitive syntax. It's almost as bad as Rust syntax.

Dosdude1:

I'll try to Objective-ly have a small rebuttal here and I do agree with you with on the linking thing.

Before Swift 4.2, Apple kept the Swift libraries self contained in the App. And this worked great. I have some Swift Apps on MacOS that I haven't updated and they still run. But Apple wanted to make the Swift Apps smaller and this is were the complexities start.

After Swift 4.2 and mostly in 5 Apple decided to make Swift part of the OS. First the apps should never have their own libraries anymore but Apple kept them for non-apple OS' like Ubuntu Linux. Or so they said. But it turns out those thinned libraries are linking to the larger Swift libraries on the OS. And this whole linking to the Main swift OS libraries and those linking to actual frameworks I agree is complex and this also makes it harder for Swift 5 to move forward on other platforms like Android and Windows. Swift 4 users have gotten the base Swift language and its toolchain to install, compile and run basic command line apps with Java or Windows interfaces.

Here's where my rebuttal starts, I've been writing Swift since version 1 and for me it took some getting used to. I would start with some basic code of Github and expand from there. At the time, I could write Objective-C and did it off and on for 20 years and I have used a sister language called AppleScript-ObjC and its still around but Apple doesn't talk about. While I was learning Objective-C, I got into AppleScript Studio and it let you write Cocoa Apps in AppleScript. It was slow as dirt but you could combine it with shell scripts and that make up for its slowness. AppleScript historically is mostly used for Automation and Automating Applications. Later AppleScript-ObjC came and a decade later came Swift.

Now I haven't written a line of Objective-C since I started using Swift. I used to be good at translating Objective-C to Swift and did this a lot in the early days when there were no Swift examples just Obj-C, but I've been away from Objective-C for so long that now it's easier to just write Swift from scratch. [ I do still use Swift data types, btw. ]

Now I don't disagree that CloneToolX should probably be an Objective-C app and in fact, I plan rewrite later this year in Objective-C to get my feet web again with language as many iOS shops are writing new code in Swift and they are maintaining code in Objective-C. Job wise; it will be best for me to get into both. It won't be a hard re-write because all I am doing use using NSTask aka Process(), to do the work. Apple's disk code for Swift uses mostly C libraries and that's just too low level and would have require a learning curve.

Back on the ugly part of this linking thing. I honestly did not know how bad the linking problem was until I encountered it last night. On the base system, Swift is non existent and that says Apple's macOS Engineers are only use C and Objective-C with maybe some JavaScript mixed in. When working with the base system, I knew there would be one or two libraries that I needed to bring in. Swift on a full OS will use the Metal API if its available for its drawing and I knew Metal is not used on the Base System. I surprised I had to bring in pieces from the Quartz. Lib.

I have written about a dozen iOS apps in the last 5 years. I am now getting around to publishing at least half of them. I've done apps in SpriteKit, SceneKit, ARKit, UIKit, AppKit all with Swift. How it works in Xcode is not much different than Objective-C. The UI links the same way in IB and you can code UI all in code as well. Now I am not a fan of SwiftUI at this time. I really don't like it right now and I'll have to watch some videos on it because I can really say how I feel about it. For now it's easier for me to use Swift in it's Cocoa / AppKit / UIKit form.

I have recently written my own Swift libraries and I've also done Swift server side. [ My libraries are linked statically and they are much cleaner than what Apple is doing ]. I like being able to make a library make it part of Swift Package Manager and distribute it within git. That part is quite nice and I have a library for my HLS Streaming Radio software that can use the same code on a server, a client and on an embedded web server with my client. Those are some great plus'. Mix that in with an Xcode workspace and you can develop the Library and Mulitple platforms all at the same time. You can do the same thing with Objective-C except there isn't a package manager builtin into the OS for it, as far I know, like it is in Swift. Swift's package manger is a pretty useful tool and Catalina's Xcode is finally supported it. In the past it was all command line.

I do agree with you on the linking thing. Can't deny that. I however, am so used to writing code in Swift, it's going to be hard for me to change. I will re-write CloneToolX later this year in Objective-C to make things easier for its embedded OS and will most likely maintain two versions of it. Maybe three if I get into SwiftUI.

I am also thinking about making the CloneToolX project open source where others can take part in adding things to it and if they want to be apart of any writes or other flavors, then that would make things much easier.

The tool overall is working great regardless of how Apple implements Swift. If it was under performant, I would re-think it.

Thank you for your input. I have seen your latest work with your macOS patched installer maker and you did an awesome job and I congratulate you on it. I will still see things from a different perspective, but I must say your latest stuff with the installer is superb. I have sent you a donation recently, I hope you are getting more donations by the day. I know none of us are in this for the money. And this is a great community that you started!

Todd

p.s.

Swift 5.1 is out and the language is moving so fast, that I have not been able to keep up and some of the its latest advances I can't even comprehend. Swift does keep you busy learning. And there doesn't seem to be a end of it leveling off. I will be happy when Apple when it does like how Objective-C is today. But with Apple having a new OS every year, along with a new Xcode, looks like there will always be a new version of Swift. This is good, bad and ugly.

 

[RogueB]

Hello to all,

MacBook Pro 5,2 (mid 2009) 17 inch, with EVO 860 SSD, and ROM successfully flashed with dosdude1's APFS ROM patch.
Running Catalina Dev. beta 3, installed via patcher 1.0b6. Two partitions active: one with Mojave 10.14.6 (beta) and another with Catalina 10.15.beta3 (dev). Both bootable.

I can confirm that your (@ASentientBot) Siri patch works as described when placed in pathway delineated in your post.
Its activation does not require a restart, or even logout; once file is installed, just click on Siri icon once (it will crash) then click on it again, and you should have siri active.
Wow, well done - thank you to every person involved in this venture.

--Maps.app does crash on my machine
--Photos.app crashes as well.
Other things seem to be fully functional.

Hope this may be of help.[/QUOTE]

 

[jasoncarle]

Like this just drop the one you downloaded and click replace then authenticate enter your password but you could also drop the original in your documents folder just in case

That worked after making the disk writable, but Siri itself still isn't working, which is a bummer. I am getting closer to just going back to HS even though that was a crappy OS.

edit: Nevermind, it was operator error... It works just fine.

 

[TimothyR734]

So far this is the only crash report I got so far for Stocks.

 

[dosdude1]

Dosdude1:

I'll try to Objective-ly have a small rebuttal here and I do agree with you with on the linking thing.

Before Swift 4.2, Apple kept the Swift libraries self contained in the App. And this worked great. I have some Swift Apps on MacOS that I haven't updated and they still run. But Apple wanted to make the Swift Apps smaller and this is were the complexities start.

After Swift 4.2 and mostly in 5 Apple decided to make Swift part of the OS. First the apps should never have their own libraries anymore but Apple kept them for non-apple OS' like Ubuntu Linux. Or so they said. But it turns out those thinned libraries are linking to the larger Swift libraries on the OS. And this whole linking to the Main swift OS libraries and those linking to actual frameworks I agree is complex and this also makes it harder for Swift 5 to move forward on other platforms like Android and Windows. Swift 4 users have gotten the base Swift language and its toolchain to install, compile and run basic command line apps with Java or Windows interfaces.

Here's where my rebuttal starts, I've been writing Swift since version 1 and for me it took some getting used to. I would start with some basic code of Github and expand from there. At the time, I could write Objective-C and did it off and on for 20 years and I have used a sister language called AppleScript-ObjC and its still around but Apple doesn't talk about. While I was learning Objective-C, I got into AppleScript Studio and it let you write Cocoa Apps in AppleScript. It was slow as dirt but you could combine it with shell scripts and that make up for its slowness. AppleScript historically is mostly used for Automation and Automating Applications. Later AppleScript-ObjC came and a decade later came Swift.

Now I haven't written a line of Objective-C since I started using Swift. I used to be good at translating Objective-C to Swift and did this a lot in the early days when there were no Swift examples just Obj-C, but I've been away from Objective-C for so long that now it's easier to just write Swift from scratch. [ I do still use Swift data types, btw. ]

Now I don't disagree that CloneToolX should probably be an Objective-C app and in fact, I plan rewrite later this year in Objective-C to get my feet web again with language as many iOS shops are writing new code in Swift and they are maintaining code in Objective-C. Job wise; it will be best for me to get into both. It won't be a hard re-write because all I am doing use using NSTask aka Process(), to do the work. Apple's disk code for Swift uses mostly C libraries and that's just too low level and would have require a learning curve.

Back on the ugly part of this linking thing. I honestly did not know how bad the linking problem was until I encountered it last night. On the base system, Swift is non existent and that says Apple's macOS Engineers are only use C and Objective-C with maybe some JavaScript mixed in. When working with the base system, I knew there would be one or two libraries that I needed to bring in. Swift on a full OS will use the Metal API if its available for its drawing and I knew Metal is not used on the Base System. I surprised I had to bring in pieces from the Quartz. Lib.

I have written about a dozen iOS apps in the last 5 years. I am now getting around to publishing at least half of them. I've done apps in SpriteKit, SceneKit, ARKit, UIKit, AppKit all with Swift. How it works in Xcode is not much different than Objective-C. The UI links the same way in IB and you can code UI all in code as well. Now I am not a fan of SwiftUI at this time. I really don't like it right now and I'll have to watch some videos on it because I can really say how I feel about it. For now it's easier for me to use Swift in it's Cocoa / AppKit / UIKit form.

I have recently written my own Swift libraries and I've also done Swift server side. [ My libraries are linked statically and they are much cleaner than what Apple is doing ]. I like being able to make a library make it part of Swift Package Manager and distribute it within git. That part is quite nice and I have a library for my HLS Streaming Radio software that can use the same code on a server, a client and on an embedded web server with my client. Those are some great plus'. Mix that in with an Xcode workspace and you can develop the Library and Mulitple platforms all at the same time. You can do the same thing with Objective-C except there isn't a package manager builtin into the OS for it, as far I know, like it is in Swift. Swift's package manger is a pretty useful tool and Catalina's Xcode is finally supported it. In the past it was all command line.

I do agree with you on the linking thing. Can't deny that. I however, am so used to writing code in Swift, it's going to be hard for me to change. I will re-write CloneToolX later this year in Objective-C to make things easier for its embedded OS and will most likely maintain two versions of it. Maybe three if I get into SwiftUI.

I am also thinking about making the CloneToolX project open source where others can take part in adding things to it and if they want to be apart of any writes or other flavors, then that would make things much easier.

The tool overall is working great regardless of how Apple implements Swift. If it was under performant, I would re-think it.

Thank you for your input. I have seen your latest work with your macOS patched installer maker and you did an awesome job and I congratulate you on it. I will still see things from a different perspective, but I must say your latest stuff with the installer is superb. I have sent you a donation recently, I hope you are getting more donations by the day. I know none of us are in this for the money. And this is a great community that you started!

Todd

p.s.

Swift 5.1 is out and the language is moving so fast, that I have not been able to keep up and some of the its latest advances I can't even comprehend. Swift does keep you busy learning. And there doesn't seem to be a end of it leveling off. I will be happy when Apple when it does like how Objective-C is today. But with Apple having a new OS every year, along with a new Xcode, looks like there will always be a new version of Swift. This is good, bad and ugly.

I can definitely see where you're coming from with that.

I've been writing Mac OS and iOS apps for quite some time as well. I actually really got into it like 5 years ago, and now absolutely love writing programs for these Apple platforms. I, of course, have used Objective-C exclusively with these projects, and have gotten extremely familiar and skilled with the language. When Apple released Swift in 2014, my immediate impression of it was that it's unnecessary. So, I decided from that day that I would never "fall into the trap" that Apple wanted developers to, and adapt completely over to Swift, killing compatibility with all older OS versions. Heck, the Xcode version and OS I use daily (OS X 10.9.5 Mavericks and Xcode 5.1.1) don't even support Swift. I also don't use Storyboards (always use old-school XIBs), base internalization, auto layout, or even ARC in some projects. All to ensure maximum compatibility; and that I have most certainly achieved.

The most interesting part about Objective-C, though, is that technically it wasn't even developed by Apple... It was intended for use as the native programming language for NeXTStep, which is where the "NS" in all the native class types comes from. This history is another cool thing that I, for some reason, always think about when writing in Objective-C. I've even written my own program for NeXT in Objective-C, using "ProjectBuilder", the precursor to Xcode, which was very fun. And no, the language itself hasn't changed a bit since then, and that I absolutely love.

Call me crazy, but I will always continue to use "old-school" programming languages, simply due to their extremely established nature, and the fact that these "old" languages (C, C++, mainly) will always be relevant. I don't want to write in some "more user-friendly" language, and hide from all the nitty-gritty that most people don't want to deal with. I like the challenges that come with "old-school", lower level programming languages, and I believe learning how to work with them makes you a much better programmer, even when using higher-level languages.

Lastly, I just want to thank you for your support, I really appreciate it. While I may not be into the most "cutting edge" in programming, there is definitely place for those who are, like yourself, and I definitely see and accept that. Thanks for all the work you've done, and I look forward to trying CloneToolX when it's all finished.

 

[ASentientBot]

Hey everybody! Nothing huge here, but I'm uploading a small update to the SkyLight/CoreDisplay wrappers that fixes a couple annoying glitches by re-implementing some functions that were previously just stubs:
• Dock rect functions: Maximizing a window will no longer send its bottom edge below the Dock, and windows will properly "stick" against its edge as in Mojave.
• Session switch function: The correct transition (cube or fade) will be used for user switching and logout.

@dosdude1 and @0403979, please update these frameworks in your patchers.

 

[TimothyR734]

The other thing I have noticed Grapher app is no longer supported or in the system utilities folder
[doublepost=1562299478][/doublepost]

Hey everybody! Nothing huge here, but I'm uploading a small update to the SkyLight/CoreDisplay wrappers that fixes a couple annoying glitches by re-implementing some functions that were previously just stubs:
• Dock rect functions: Maximizing a window will no longer send its bottom edge below the Dock, and windows will properly "stick" against its edge as in Mojave.
• Session switch function: The correct transition (cube or fade) will be used for user switching and logout.

@dosdude1 and @0403979, please update these frameworks in your patchers.

Awesome well done I think the stock app is linked to the News App as you can see in my post above Dosdude1

 

[ASentientBot]

@TimothyR734 -- Thanks for the crash report. It doesn't look Metal related, weirdly enough it looks like Stocks is simply trying to load a framework that doesn't exist. It's looking for:

/System/iOSSupport/System/Library/PrivateFrameworks/Stocks/NewsArticles.framework

But the real path to that framework is:

/System/iOSSupport/System/Library/PrivateFrameworks/NewsArticles.framework

I suppose you might try copying the second path to the first and see if that fixes it? I can't replicate the message you're seeing. In any case, I think it's a beta bug and not a SkyLight/CoreDisplay related issue, thankfully.

 

[dosdude1]

Hey everybody! Nothing huge here, but I'm uploading a small update to the SkyLight/CoreDisplay wrappers that fixes a couple annoying glitches by re-implementing some functions that were previously just stubs:
• Dock rect functions: Maximizing a window will no longer send its bottom edge below the Dock, and windows will properly "stick" against its edge as in Mojave.
• Session switch function: The correct transition (cube or fade) will be used for user switching and logout.

@dosdude1 and @0403979, please update these frameworks in your patchers.

Nice job! You're getting to be quite good at reverse engineering. Thanks once again!

 

[ASentientBot]

Timothy, Grapher is still there for me.

[doublepost=1562299672][/doublepost]

Nice job! You're getting to be quite good at reverse engineering. Thanks once again!

I'm getting there... still have a lot to learn before I catch up with the real experts like yourself. Always neat to see how things work though

 

[al3bsi]

how i can install catalina ??

 

[TimothyR734]

I have reinstall Cat I deleted CoreDisplay and was going to drop the new patched version in it place but is one I dislike about macOS drag and drop sucks got stuck preparing to move dialog never had those messages with windows

 

[jasoncarle]

Hey everybody! Nothing huge here, but I'm uploading a small update to the SkyLight/CoreDisplay wrappers that fixes a couple annoying glitches by re-implementing some functions that were previously just stubs:
• Dock rect functions: Maximizing a window will no longer send its bottom edge below the Dock, and windows will properly "stick" against its edge as in Mojave.
• Session switch function: The correct transition (cube or fade) will be used for user switching and logout.

@dosdude1 and @0403979, please update these frameworks in your patchers.

Can I just drop this where they belong, similar to the Siri fix, and they will work?

 

[avz]

I have reinstall Cat I deleted CoreDisplay and was going to drop the new patched version in it place but is one I dislike about macOS drag and drop sucks got stuck preparing to move dialog never had those messages with windows

It is better to do it in a single user mode. It certainly can work "on the fly" but you definitely need a healthy dose of luck to do it successfully.

 

[ASentientBot]

Can I just drop this where they belong, similar to the Siri fix, and they will work?

Yes, but don't do it using the Finder. The entire UI relies on those things, so replacing one tends to freeze/crash Finder before it finishes copying. Then you'll be stuck with a non-booting system.

Either sudo cp -R them in Terminal (you'll still need to force-reboot immediately afterwards), use single-user mode, or boot from another drive to perform the replacements.

Edit: Before modifying system files in a booted Cat system, you'll need to run sudo mount -uw / (ignore an error message about "AppleInternal").

 

[TimothyR734]

I am not good with terminal stuff got 6 iMacs I bricked trying to use the terminal I like to just to replace like I do with hybrid patches I tried again about ready ro rm/f my iMac hopefully the patcher gets updated with the new patched core display

 

[macsba]

Hello dosdude1;

On your main webpage, could you please place a link for the Catalina macOS installer and patches.

Thank you.

P.S. I'm getting lost in the links in this forum.

 

[tintelor]

Make sure your system has the latest, APFS-comaptible firmware installed. You can do this by installing this package. Your system must be plugged in in order for the firmware to be flashed.

My mistake, mine is MBP7,1 (13" mid-2010). Can I still use the firmware attached?

 

[TimothyR734]

It is better to do it in a single user mode. It certainly can work "on the fly" but you definitely need a healthy dose of luck to do it successfully.

I agree If I was good with the terminal I would Julians patcher but I got so lost trying it I like things simple or use an install script

 

[jackluke]

Hey everybody! Nothing huge here, but I'm uploading a small update to the SkyLight/CoreDisplay wrappers that fixes a couple annoying glitches by re-implementing some functions that were previously just stubs:
• Dock rect functions: Maximizing a window will no longer send its bottom edge below the Dock, and windows will properly "stick" against its edge as in Mojave.
• Session switch function: The correct transition (cube or fade) will be used for user switching and logout.

@dosdude1 and @0403979, please update these frameworks in your patchers.

Well done about your new Catalina patches, keep tracking of all your modifications to the SkyLight when you'll re-use the one from 10.14.6 that I have the impression will be more aligned to the Catalina beta one, so it could contain additional functions useful for Catalina and some new functions for Mojave.

 

[jasoncarle]

Yes, but don't do it using the Finder. The entire UI relies on those things, so replacing one tends to freeze/crash Finder before it finishes copying. Then you'll be stuck with a non-booting system.

Either sudo cp -R them in Terminal (you'll still need to force-reboot immediately afterwards), use single-user mode, or boot from another drive to perform the replacements.

Edit: Before modifying system files in a booted Cat system, you'll need to run sudo mount -uw / (ignore an error message about "AppleInternal").

In that case, I think I'll wait a bit and do it when I install the next Beta.

 

[Flacko]

FYI, Collin will be adding this in the next patcher release. I also confirmed his solution of just copying over the missing Mojave AppleIntelPIIXATA.kext into the Plugins directory of the Catalina IOATAFamily.kext works fine.

Great work, many thanks.

 

[TimothyR734]

I got the Home,Stocks and Voice Memo's working again I don't know if the Cat reinstall fixed the issues or by replacing the patched versions A of Skylight and CoreDisplay fixed it but still stumped about Grapher I don't use it but it had a big question mark on it and the messages said macOS Catalina doesn't support running 32 bit software so I deleted it and then did a Cat reinstall but its not back

 

[pkouame]

Dosdude1:

I'll try to Objective-ly have a small rebuttal here and I do agree with you with on the linking thing.

Before Swift 4.2, Apple kept the Swift libraries self contained in the App. And this worked great. I have some Swift Apps on MacOS that I haven't updated and they still run. But Apple wanted to make the Swift Apps smaller and this is were the complexities start.

After Swift 4.2 and mostly in 5 Apple decided to make Swift part of the OS. First the apps should never have their own libraries anymore but Apple kept them for non-apple OS' like Ubuntu Linux. Or so they said. But it turns out those thinned libraries are linking to the larger Swift libraries on the OS. And this whole linking to the Main swift OS libraries and those linking to actual frameworks I agree is complex and this also makes it harder for Swift 5 to move forward on other platforms like Android and Windows. Swift 4 users have gotten the base Swift language and its toolchain to install, compile and run basic command line apps with Java or Windows interfaces.

Here's where my rebuttal starts, I've been writing Swift since version 1 and for me it took some getting used to. I would start with some basic code of Github and expand from there. At the time, I could write Objective-C and did it off and on for 20 years and I have used a sister language called AppleScript-ObjC and its still around but Apple doesn't talk about. While I was learning Objective-C, I got into AppleScript Studio and it let you write Cocoa Apps in AppleScript. It was slow as dirt but you could combine it with shell scripts and that make up for its slowness. AppleScript historically is mostly used for Automation and Automating Applications. Later AppleScript-ObjC came and a decade later came Swift.

Now I haven't written a line of Objective-C since I started using Swift. I used to be good at translating Objective-C to Swift and did this a lot in the early days when there were no Swift examples just Obj-C, but I've been away from Objective-C for so long that now it's easier to just write Swift from scratch. [ I do still use Swift data types, btw. ]

Now I don't disagree that CloneToolX should probably be an Objective-C app and in fact, I plan rewrite later this year in Objective-C to get my feet web again with language as many iOS shops are writing new code in Swift and they are maintaining code in Objective-C. Job wise; it will be best for me to get into both. It won't be a hard re-write because all I am doing use using NSTask aka Process(), to do the work. Apple's disk code for Swift uses mostly C libraries and that's just too low level and would have require a learning curve.

Back on the ugly part of this linking thing. I honestly did not know how bad the linking problem was until I encountered it last night. On the base system, Swift is non existent and that says Apple's macOS Engineers are only use C and Objective-C with maybe some JavaScript mixed in. When working with the base system, I knew there would be one or two libraries that I needed to bring in. Swift on a full OS will use the Metal API if its available for its drawing and I knew Metal is not used on the Base System. I surprised I had to bring in pieces from the Quartz. Lib.

I have written about a dozen iOS apps in the last 5 years. I am now getting around to publishing at least half of them. I've done apps in SpriteKit, SceneKit, ARKit, UIKit, AppKit all with Swift. How it works in Xcode is not much different than Objective-C. The UI links the same way in IB and you can code UI all in code as well. Now I am not a fan of SwiftUI at this time. I really don't like it right now and I'll have to watch some videos on it because I can really say how I feel about it. For now it's easier for me to use Swift in it's Cocoa / AppKit / UIKit form.

I have recently written my own Swift libraries and I've also done Swift server side. [ My libraries are linked statically and they are much cleaner than what Apple is doing ]. I like being able to make a library make it part of Swift Package Manager and distribute it within git. That part is quite nice and I have a library for my HLS Streaming Radio software that can use the same code on a server, a client and on an embedded web server with my client. Those are some great plus'. Mix that in with an Xcode workspace and you can develop the Library and Mulitple platforms all at the same time. You can do the same thing with Objective-C except there isn't a package manager builtin into the OS for it, as far I know, like it is in Swift. Swift's package manger is a pretty useful tool and Catalina's Xcode is finally supported it. In the past it was all command line.

I do agree with you on the linking thing. Can't deny that. I however, am so used to writing code in Swift, it's going to be hard for me to change. I will re-write CloneToolX later this year in Objective-C to make things easier for its embedded OS and will most likely maintain two versions of it. Maybe three if I get into SwiftUI.

I am also thinking about making the CloneToolX project open source where others can take part in adding things to it and if they want to be apart of any writes or other flavors, then that would make things much easier.

The tool overall is working great regardless of how Apple implements Swift. If it was under performant, I would re-think it.

Thank you for your input. I have seen your latest work with your macOS patched installer maker and you did an awesome job and I congratulate you on it. I will still see things from a different perspective, but I must say your latest stuff with the installer is superb. I have sent you a donation recently, I hope you are getting more donations by the day. I know none of us are in this for the money. And this is a great community that you started!

Todd

p.s.

Swift 5.1 is out and the language is moving so fast, that I have not been able to keep up and some of the its latest advances I can't even comprehend. Swift does keep you busy learning. And there doesn't seem to be a end of it leveling off. I will be happy when Apple when it does like how Objective-C is today. But with Apple having a new OS every year, along with a new Xcode, looks like there will always be a new version of Swift. This is good, bad and ugly.

Hi - I agree with your perspective on the whole Swift vs. ObjC thing. With 25+ years of C, C++, ObjC (heck SmallTalk and NextStep) experience behind me, Swift is a breath of fresh air and a legitimate response to years of stagnation while software language science has evolved by leaps and bounds since the 90s. One of the issues with Swift has been the design by committee open-source approach that Apple boldly took. Largely because of Chris Lattner (imho a genius in his own right - just take a look at llvm) The result has been great for fsf open source geeks like me, but watching the sausage being made has frustrated many. Luckily Swift 5+ is a major step towards stability and once they achieve true binary compatibility...

The modern language purists will recognize its strengths, hands down. Then again there is absolutely nothing you can't do in ObjC - it's perfect for writing utilities, drivers etc. It affords the same low-level access as C and C++ with a little SmallTalk inspired object-oriented messaging sprinkled in. I believe all these languages are just different tools to be selected for the right job.

Swift UI is in its infancy, currently I fail to see its appeal and won't waste my time anymore with it. Just another example of Apple wasting precious resources on shiny new toys we really don't need, but who knows maybe it will mature into something useful...

Good job on CloneToolX - you've already done the heavy lifting in Swift - port to something else only if you have to. Time is also a precious commodity...

 

[bbfc]

I have reinstall Cat I deleted CoreDisplay and was going to drop the new patched version in it place but is one I dislike about macOS drag and drop sucks got stuck preparing to move dialog never had those messages with windows

I had this issue trying to install the Hybrid patches. The copying files dialog just sticks at preparing. I have to restart Finder, which doesn’t often work. Usually have to restart my Mac and restore the original versions of the files using Single-User Mode. It kept doing it so I gave up trying to install the patched version of HIToolbox and CoreUI.