27 ms·

Apple announces full Swift rewrite of the Foundation framework (2022)

434 points by frizlab 4y ago

leo150 4y ago
Wait, no more "po [$arg1 reason]"?
Bud 4y ago
[dead]
wlesieutre 4y ago
Similar post by Michael Tsai with some quick summary points of the impact of this: https://mjtsai.com/blog/2022/12/12/the-swifty-future-of-foundation/ https://mjtsai.com/blog/2022/12/12/the-swifty-future-of-foun...
- ofcourseyoudo 4y ago
  Thanks for that, always appreciaet Tsai's perspective and this part stuck out to me: >it sounds like the plan is to rewrite it in Swift and extend Swift to allow Objective-C to call the Swift implementation of the old API
  - phillco 4y ago
    I really like his style of 1) summarising articles he links to 2) attaching follow up from elsewhere on the internet, it's a nice pattern I'm surprised hasn't been more widely copied
- xenadu02 4y ago
  Not sure why but most people don't seem to have noticed that people outside Apple will now be able to contribute to Foundation and these contributions will ship across all platforms.
  - lapcat 4y ago
    Free labor for the world's most profitable corporation. Looking forward to it. And then they still take a cut of your revenue.
    - sunshinerag 4y ago
      You also mean “paid labour From the worlds most profitable corporation” right?
      - lapcat 4y ago
        No?
the_solenoid 4y ago
Todd, you owe me $20. (Todd said this would never happen) Also, this is great news, and it will be interesting to see what kind of real-world changes in performance this has.
- mpweiher 4y ago
  Things will get even slower.
  - zuhsetaqi 4y ago
    Why do you think it’ll be slower? The article says the opposite
  - KerrAvon 4y ago
    Available data so far seems to show that the pure Swift implementations are faster than the Objective-C ones even when called from ObjC clients. I don't have a link, so feel free to treat as hearsay, but FYI.
    - mpweiher 4y ago
      You don't have a link to the data because this is not true. Swift is generally slower than Objective-C, often significantly so. There are cases where it is faster, but those are rare. Yes, I have measured. One example is JSON and Swift codable, which is comically slow, see: Somewhat Less Lethargic JSON Support for iOS/macOS, Part 1: The Status Quo https://blog.metaobject.com/2020/04/somewhat-less-lethargic-json-support.html https://blog.metaobject.com/2020/04/somewhat-less-lethargic-... Punch line: Swift codable does around 10MB/s, despite all the supposed performance goodies and compiler support everyone always talks about and nobody appears to ever measure. A pure Objective-C implementation does 284MB/s. I also did a more general survey for my book[1]. While that's been a while, I haven't seen any indication that things have fundamentally changed, and lots of indications that they haven't.
      - astrange 4y ago
hyperhello 4y ago
“A reimplementation of Calendar in Swift is 1.5x to 18x as fast as the C one (calling from Swift in various synthetic benchmarks like creation, date calculation).” I’m sure it is, but this is not solving the right problem at all. Calendar is all UI. It needs to be lovingly gone over, not this.
- stephencanon 4y ago
  That quote is talking about the Foundation type named Calendar (https://developer.apple.com/documentation/foundation/calendar https://developer.apple.com/documentation/foundation/calenda...), not Calendar.app.
- newZWhoDis 4y ago
  Calendar/Date is the foundation for all time handling in iOS apps. If you see a string with a date in it it was probably handled by this system.
- jeremy_wiebe 4y ago
  This post is referring to NSCalendar and Swift's Calendar class. > NSCalendar objects encapsulate information about systems of reckoning time in which the beginning, length, and divisions of a year are defined. > The Swift overlay to the Foundation framework provides the Calendar structure, which bridges to the NSCalendar class. https://developer.apple.com/documentation/foundation/nscalendar https://developer.apple.com/documentation/foundation/nscalen...
- mpweiher 4y ago
  Note the somewhat disingenuous performance claim: The reimplementation itself is not 1.5x to 18x as fast as the C one. It is calling from Swift that is faster. Yes, they correct in the parenthesis, but that's not how parenthetical expressions work: A parenthetical expression is extra information added to a sentence or question that clarifies, explains, or adds information without changing the basic meaning. Think of it as an aside providing readers with helpful information that they don’t absolutely have to have, but that is helpful to them. https://grammar.yourdictionary.com/style-and-usage/parenthetical-expression-types-and-usage.html https://grammar.yourdictionary.com/style-and-usage/parenthet... So basically, they are fixing the problem they've been having with bridging performance, which of course is due purely to them mis-designing Swift in such a way that it doesn't bridge well with all the existing code they have.
justinator 4y ago
[flagged]
- gl-prod 4y ago
  anyways
eatonphil 4y ago
I don't know Swift too well but my impression is that the support on Linux within the Foundation is not complete. (Also, is Foundation the same thing as what one might normally term a standard library? I can't tell.) Does this change imply better (eventual) support on non-Darwin systems? Or maybe I've misread it and the change is unrelated.
- mplewis9z 4y ago
  > my impression is that the support on Linux within the Foundation is not complete It is not, but it's like 95% of the way there in my experience - most things that are missing are relatively recent additions that have some complex OS interactions, like filesystem I/O with language-level concurrency features. > Does this change imply better (eventual) support on non-Darwin systems? Yes. The non-Darwin Foundation version is already rewrite that takes a lot of effort to keep in lock-step with the closed-source Objective-C version, so unifying the implementations in Swift will both reduce the amount of maintenance effort and promote non-Darwin platorms to more of a "first-party" status. > Also, is Foundation the same thing as what one might normally term a standard library? It's more of a standard library++, including some things that other languages include in their standard libraries (Date/Time models) but also other things that are common to put in third-party libraries (networking, etc.). You do not need to use Foundation for basic things like arrays or concurrency that are built into the normal standard library.
  - eatonphil 4y ago
    > complex OS interactions, like filesystem I/O with language-level concurrency features. Do you mean like io_uring? That wouldn't be too surprising. Even Go doesn't have that in the standard library yet. > so unifying the implementations in Swift will both reduce the amount of maintenance effort and promote non-Darwin platorms to more of a "first-party" status. That's what I was hoping for. Thanks!
  - avisser 4y ago
    <bikeshed> It feels off to call things like Array part of any library when you have array literal syntax `let oddNumbers = [1, 3, 5, 7, 9, 11, 13, 15]` I'd call that a language feature. Or maybe with Swift there is a blurry line between the two?
KingLancelot 4y ago
9 years after the created this language they’re only now beginning to do this?
- deleted 4y ago
  [deleted]
dcow 4y ago
I am pretty certain that most of high level use cases for Rust could be replaced with Swift, with increased developer velocity, if Swift was actually cross platform. And that's coming from a Rust fan. It will be interesting to see how effective this rewrite is.
- kitsunesoba 4y ago
  I would love to be able to write cross-platform desktops apps in Swift. The language isn't perfect of course but I enjoy it a lot more than the alternatives I've tried. That possibility is still a ways down the road of course but Foundation getting a cross platform rewrite is a nice step in that direction.
  - rattray 4y ago
    If you or others on this thread are interested in working on a Swift compiler for Windows, please reach out to me :) a good friend is hiring a team to make this happen.
    - Someone 4y ago
      How will that be different from Apple’s Swift toolchain for Windows (https://www.swift.org/blog/swift-on-windows/ https://www.swift.org/blog/swift-on-windows/)?
      - rattray 4y ago
        https://youtu.be/bOMQiMxh5Bc?t=430 https://youtu.be/bOMQiMxh5Bc?t=430 relevant listen is about 2min long
        Someone 4y ago
        To me, that sounds as if most of the work would not be on the compiler but on improving the development experience (IDE, debugging support). On the other hand, your comment said ”working on _a_ Swift compiler for Windows”. To me, that sounded like a new compiler, not adding missing features to the existing one. Which of the two is it?
deleted 4y ago
[deleted]
pvg 4y ago
Very short discussion last month: https://news.ycombinator.com/item?id=33923484 https://news.ycombinator.com/item?id=33923484
ChrisMarshallNY 4y ago
This will take a while, but I'm looking forward to it. It's probably another big step towards "Swift everywhere," without worrying about bridging to C. I've been doing little but Swift since 2014, and really like the language. I'm still "on the fence" about SwiftUI, but that's mostly because of the level of support from Apple, and the [im]maturity of the system. This will help with that.
- manmal 4y ago
  Yes, and it means Swift scripts and modules that don’t reference UIKit/AppKit/SwiftUI/Combine will run on Linux and possibly Windows with zero or little modification. I‘m a little sad though that they didn’t start this endeavor years ago, because IMO Rust has already built so much momentum that it will win (for the popular, medium to long term definition of „winning“).
  - ChrisMarshallNY 4y ago
    I don't particularly care, whether or not Swift ever leaves the Apple ecosystem (like ObjC). In that domain, Rust will never "win." I think that Rust is an awesome server language, though, and I'm glad to see it gain traction. I just hope that it doesn't get trashed by a bunch of junk dependencies, written in it. I find using apps written, using hybrid systems, or PWAs, to be quite painful (on Apple devices -and that includes that awful JS TVOS system), so I am a big proponent of real native apps.
    - manmal 4y ago
      I think whoever „wins“, it would be necessary to have good interop at least. Currently, Rust devs are integrating core libs into native iOS apps by going the C route. All this work to make everything memory safe, and then this.
      - mrtesthah 4y ago
        Swift-based interop would provide richer type information. See how swift-bridge takes advantage of it: https://github.com/chinedufn/swift-bridge https://github.com/chinedufn/swift-bridge
birdymcbird 4y ago
Someone knowing existing pattern help me understand this. right now when i use these “foundation” apis in swift it is doing c call? so they rewriting now the c code in swift? (dont do ios or mac code so now sure) me dont understand what make it faster now. i once wrote some jni code to call c++ library from java. does mean there some similar code to do cross language call? they get rid of it and so things now faster? offtopic but debugging crashes in c++ over jni call was super hard. logs not work and me not figure out how to fix. wonder if they had similar “troubles” and this make everything easier :) always feel skeptical when seeing large code base have “rewrite”. try many time in me career thinking there good reasons but super hard and not best value in end
- machinekob 4y ago
  It's a lot of obj-c/c on apple and syscalls on other platforms, I think the biggest point its to get rid of annoying obj-c calls and make it fully cross platform as its a nightmare for both safety and performance in many cases to call objc.
- saagarjha 4y ago
  Most of Foundation on Darwin used to call into Objective-C code. This is going to be replaced with Swift code while keeping the API the same.
  - Reason077 4y ago
    Conversely, will existing Obj-C (and hybrid Swift/Obj-C) apps be able to call the new Swift Foundation? And will it be binary-compatible with existing apps, or will Apple just ship a separate compatibility version of Foundation for use by legacy apps?
    - saagarjha 4y ago
      Yes, it’ll be binary compatible.
      - 4y ago
alberth 4y ago
What remaining Apple frameworks are not yet written in Swift?
- saagarjha 4y ago
  Most of them. Very few frameworks are actually written primarily in Swift.
  - alberth 4y ago
    Would the macOS kernel (Mach) ever be rewritten in Swift? And if so, what benefit would it provide?
    - deleted 4y ago
      [deleted]
    - mplewis9z 4y ago
      I doubt the entire kernel would - there are low-level, memory-unsafe operations that an operating system performs that Swift _could_ do, but it would be fighting the design of the language and likely not a great trade-off for the kernel developers. But pieces absolutely could be. The benefit would be compile-time checking for memory safety issues (reducing crashes) and language-level concurrency (fewer race conditions and a much easier path to parallelize single-threaded code for performance).
      - MBCook 4y ago
        I believe all the code on the Secure Enclave is now Swift. I believe they use a special mode/analyzers to ensure only the “ok” stuff is used. Perhaps no memory allocation, for example. It sounds to me like Apple would like Swift, perhaps with some extra tooling, to be able to handle the Mach kernel. I don’t know if they’ll go that far though.
        saagarjha 4y ago
        Definitely not, it’s just used for some parts.
davidkuennen 4y ago
Apple has such an unpredictable stance on software development. For example after all these years and lots of requests for such a feature it's still not possible to get notified about new reviews for your apps, but it's possible to get notified when a user edits a review after you've replied to it.
- deleted 4y ago
  [deleted]
- rufius 4y ago
  Apple’s style reminds me a lot of something I once read (and later experienced) about Japan and tourism: > (roughly) Japan is a country for the Japanese. While they may welcome you and invite you to experience their country and culture, the country is very much setup to serve the Japanese populace. Apple feels similarly. They build what they need and enough to capture the revenue they want, but I don’t perceive them to really cater to external needs beyond what will monetize.
  - threeseed 4y ago
    > but I don’t perceive them to really cater to external needs beyond what will monetize So then why does all of Apple's operating systems and apps receive updates at all. Your argument is completely illogical.
- j-f1 4y ago
  I’m not sure about macOS, but on iOS you can install the App Store Connect app (https://apps.apple.com/app/id1234793120 https://apps.apple.com/app/id1234793120) and then enable notifications for new reviews from there. ([app] → Notifications → Mobile → Reviews, [your initials] → Notifications → Customer Reviews)
psmyrdek 4y ago
How prospective it is to jump on the iOS bandwagon in 2023?
- deleted 4y ago
  [deleted]
- emehex 4y ago
  Learning iOS (Swift) could be a gateway to the next-generation of platforms: carOS, realityOS (AR/VR). Or both of these efforts could be complete duds!
meitham 4y ago
Could someone please explain what exactly is the “Foundation”?
- oneplane 4y ago
  It's the base framework where types like NSObject, NSString, NSDictionary etc. are defined. It's right there in the article. It also explains why it exists, what others exist, and what a rewrite will bring.
- KyeRussell 4y ago
  It’s not respectful to not read the link and instead ask somebody to summarise it for you.
  - meitham 4y ago
    You’re making the wrong assumption! I have read the article before I asked, and still have no idea what it is! Saying it provides these abstraction NSObject, NSString, NSArray tells me nothing! The article is clearly written towards readers familiar with Apple ecosystem.
    - herodotus 4y ago
      Objective-C is an object-oriented programming language that is essentially a super-set of C. In fact the earliest implementation of Objective C, if I recall correctly, translated Objective-C code to C. The only built in types in Objective-C are the C types, like int, char and so on. The "Foundation" is a set of classes that implement many useful types that all inherit from a superclass called NSObject. The "NS" prefix refers to Next Step, the name of the company that Steve Jobs started and where Foundation was first created. One of the advantages of this scheme is that it is possible to have heterogeneous collections (like an array of objects, where the objects do not all have to be of the same type/class). Underneath the NS foundation (whose headers are all in Objective-C) is something called Core Foundation, which implements the same classes, but in pure C. To do this well requires huge programming discipline, especially around memory management, and much of that pain is taken away by using the NS classes. Swift has already started replacing some of the foundation classes, NSString and NSDictionary, for example, giving them the names String and Dictionary without the cumbersome name-space two letter prefix. I suspect that some of this rewrite may still "bridge" to the CF classes, but in other cases, it would be much better to simply write the class in its entirety in Swift. I hope that helps.
macinjosh 4y ago
I was in a line once at WWDC in 2011. I happened to be in front of a group of Apple engineers. I overheard them discussing a rumored functional-ish language that Apple was to switch to from Obj-C. They didn't know what it was but they seemed skeptical that it would ever be put into real use. Glad to see it only took 11 years for it to permeate down to the Foundation framework. :)
- whimsicalism 4y ago
  Seems generous to describe as functional language, but I guess if you're coming from Obj-C...
- deleted 4y ago
  [deleted]
andrewmcwatters 4y ago
> A reimplementation of Calendar in Swift is 1.5x to 18x as fast as the C one (calling from Swift in various synthetic benchmarks like creation, date calculation). These sorts of statements in the industry always make me ask, "So did you guys make something terribly slow first, and then bring performance back close to where it originally was?" I'm not sure if the current Calendar app was ported to Swift, was originally Objective-C based, and such efforts to move Foundation to Swift will just... make Calendar fast again? Also, Calendar doesn't seem to be particularly slow in the first place. But I love performance engineering, and quality of life is big, so... hey cool.
- MBCook 4y ago
  They’re not talking about the app. They’re talking about the Calendar class in Foundation.
- munificent 4y ago
  > "So did you guys make something terribly slow first, and then bring performance back close to where it originally was?" In this case, the answer is basically, "yes". Objective-C is a neat language and really powerful in terms of flexibility and extensibility. But it gets that by essentially dynamically typed. It's Smalltalk duct taped onto C. Dynamically typed languages are much slower unless you do lots of very powerful JIT magic, and even then they still tend to be quite a bit slower than most statically typed compiled languages. Building Swift on top of an Objective-C core library makes a lot of sense in terms of getting Swift adoption when Swift was new. But in terms of performance, it's sort of like building a concrete bunker on top of a straw hut. You really want the bottom of your stack to be the faster, statically typed language. Then you can layer dynamic scripting languages on top for the users who want it.
bfrog 4y ago
So apple seems to be dropping c like languages, Microsoft says new stuff should not be written in c like languages anymore, and google has steadily worked towards using rust and go in place of c and c++ where it makes sense to do so it seems. There seems to be a trend here.
- phpisthebest 4y ago
  >>Microsoft says new stuff should not be written in c like languages anymore Microsoft is dropping C#? Source for that?
  - bfrog 4y ago
    C# is a lot closer to Java if anything, should clarify to be c and c++
  - mplewis9z 4y ago
    Calling C# a C-like language is like saying JavaScript is a descendant of Java.
  - AppleBananaPie 4y ago
    could be worded better but from context in the sentence I read that as c/c++
  - jon-wood 4y ago
    I think the GP probably poorly phrased that. “Memory unsafe languages” would be a better term, apart from the basic syntax C# really isn’t very C-like.
  - ccouzens 4y ago
    Based on the context I think by "c like" they meant languages with a culture of dealing with raw pointers. c# is c by name and curly braces, but primarily uses managed memory
  - diroussel 4y ago
    C# is not a C-like language. It's a managed runtime with garbage collection. However Mark Russinovich, CTO of Azure did say that it's time to drop C and C++ https://twitter.com/markrussinovich/status/1571995117233504257 https://twitter.com/markrussinovich/status/15719951172335042...
w10-1 4y ago
Correction: rewrite of PARTS of Foundation There already was an open-source project to rewrite ALL of foundation, but it had stalled on the shores of having to re-implement everything: https://github.com/apple/swift-corelibs-foundation The news is actually that Apple is now instead trying to define the bits/parts to support via Swift on all platforms (the original API's will always be supported on Darwin). The announcement: https://www.swift.org/blog/future-of-foundation/ The discussion, with hairy details about which bits, esp. for async: https://forums.swift.org/t/what-s-next-for-foundation/61939/103 The plan is to divide up Foundation into more- and less-essential parts, to get more-essential parts locked down so people can rely on them. What's Foundation? Swift's most-core library is the stdlib, tightly coupled to the compiler/language version, providing things like arrays, dictionary, etc., and available wherever Swift is. Beyond that, Foundation is the library with core API's for common features, e.g., for dates and concurrency. Stdlib is fully cross-platform and Swift-specific, but Foundation is a beast with API's dating to NExT with support for 20 years of API's. Microsoft famously arrived at porridge for an operating system by maintaining backwards compatibility. Apple has cracked open Swift by developing in the open, but it's still Apple-funded and Apple-driven. Library and some integration support for other platforms has always had to come from community (notably compnerd's heroic effort to make-things-work on windows, and a revolving cast wanting Linux support for their server API's). But there's no good reason to impose the whole Foundation history on other platforms. And there may be a movement inside Apple to migrate internal code to newer async API's, designed after the recent Apple-silicon generation. For developers with server experience and some free time in a tech lull, it could be a good opportunity to help rebuild a new, er, foundation for computing on all devices, that's native but type- and memory-safe. The community is large and mature, but there is plenty of room for others.
- deleted 4y ago
  [deleted]
- smoldesu 4y ago
  It simply sounds like there isn't much demand for Swift from the Open Source community. Apple certainly makes a big push for it internally, but outside their platform, Swift doesn't have much momentum. If Apple wants people to use Swift like a first-class runtime, they should stop treating third-parties like second-class citizens. They have $200 billion dollars in cold, hard cash - surely some of it could go towards the selfless development of a universal future computing platform, right?
Gigachad 4y ago
The removal of C from Android and iOS is going to pay off massively. The current state of things where every government is sitting on an endless collection of exploits is not ideal.
- smoldesu 4y ago
  Considering that both Google and Apple are cardholding members of PRISM, it sounds like a bit of a frying pan vs fire situation to me.
  - typon 4y ago
    Yes, but that's OUR surveillance and we're cool with that
    - sbaiddn 4y ago
      Id rather be spied on by foreigners who couldn't do anything about my eccentricities even if they cared. When you're own government's security services are spying on you, they own you.
      - Gigachad 4y ago
        The options weren't foreign government or local government, the current state is both, the future is local only. It's clearly an improvement. These security exploits also get used by local police who wouldn't have access to the top government access used for terrorists.
        deleted 4y ago
        [deleted]
        deleted 4y ago
        [deleted]
        deleted 4y ago
        [deleted]
Octokiddie 4y ago
The article quotes this: > With a native Swift implementation of Foundation, the framework no longer pays conversion costs between C and Swift, resulting in faster performance. and this: > A reimplementation of Calendar in Swift is 1.5x to 18x as fast as the C one (calling from Swift in various synthetic benchmarks like creation, date calculation). First, that range of 1.5x-18x is kind of huge. Why? Second, why would the intro with C be such a big performance penalty even assuming it's just 1.5x? I know there must be an overhead, but why so large? Also, why single out the Calendar? Is it somehow representative?
- dvh 4y ago
  I know nothing about their c codebase but I assume it's because when the language is hard, you tend to keep it as simple as possible. When every line stops being a foot gun, you start using optimizations you wouldn't dare before.
  - bborud 4y ago
    That's a plausible explanation which I find to have support in personal experience.
- vkou 4y ago
  More importantly, why single out something like date calculation? Does that really eat a meaningful number of CPU cycles that needs to be optimized?
- haimez 4y ago
  I’m not deeply familiar with swift, objective-C or the next-step APIs, but it seems like they’re describing the difference between a (virtual?) function call (ie: swift to swift) vs a “message passing operation” in objective C. If that assessment is correct, then it’s really an exercise in small costs adding up quickly. If you call through the function pointer you have way lower latency, and if you call through the same operation hundreds of times to render a single screen (the calendar) inside of the render loop where latency matters- that’s measurably better. Especially on a device that tries to throttle CPU frequency to save battery power. This is somewhat analogous to the same arguments that can be had about JIT compiled languages having the the opportunity to exceed performance of AoT compiled ones because of inlining opportunities- except in this case I don’t know if the call has any chance of being actually inlined so much as at least bypassing the message passing machinery overhead.
singularity2001 4y ago
It makes me so sad that swift, a compiled language more beautiful than Rust IMO, has such inferior support outside the Apple garden.
- deleted 4y ago
  [deleted]
thrwawy74 4y ago
Is there anything genuinely innovative about Swift or is it just another "cross-platform scripting language" that I'll only see on 1 platform? The only reason I learned Powershell is because I have to admin for Windows. At least Powershell is interesting for its pipeline and object handling. I get not one spark of joy from Swift, and the comments I see are "at least we're not writing C anymore". Stockholm syndrome. Sorry this is so negative, but I can't get excited about $NewLanguage unless I know it offers real benefit. I have drunk the Rust koolaid, and for very good reasons. What am I missing in Swift?
- yw3410 4y ago
  If I recall Swift has a very interesting ABI for generics. 1. https://faultlore.com/blah/swift-abi/ https://faultlore.com/blah/swift-abi/
  - thrwawy74 4y ago
    I appreciated this comment. This is something I hadn't seen :-)
- lloydatkinson 4y ago
  I've never done any Mac or iOS development and even I can see this is a strange question. I don't know why you think it's a scripting language, or how it compares in anyway to powershell?
- nolimitsky 4y ago
  [flagged]
- deleted 4y ago
  [deleted]
- mrtksn 4y ago
  It’s pleasant to use, that’s the main thing about Swift. A very Apple thing to be honest, so just like most of the Apple products it’s very good in few thing and good enough in others and probably nothing is completely new. The overall experience is pleasant. Apple is building just as pleasant tooling around it, Swift Playgrounds is amazing for example. Newbies can learn coding by doing some exercises disguised as games but that’s not what’s amazing, what’s amazing is that you can make full apps with all the libraries and Swift packages and SwiftUI. Apple did good job hiding the boilerplate away, did good job removing the decision making about the project file structure and created an intuitive interface where you can just code without worrying about anything else. In 2020s, Swift is probably the only language with tooling that lets you just code your ideas and deploy without dealing with anything else. Like creating a Word document and writing your thoughts down straightforward. I don’t know if submitting from Swift Playgrounds to the AppStore has been released but the beta I was trying last month had this functionality. From idea to market, start to finish integration.
stephc_int13 4y ago
This is an other step in the direction to a Swift-only Apple platforms. I don't think it would be worth my time to even buy a other macOS device to port my framework. I don't think they will get any benefit from this.
- musicale 4y ago
  It's a good question as to how long Apple will support calling its APIs from C++ via Objective-C++. I don't see any good reason for them to deprecate the ObjC-Swift bridge, but I guess they could decide it's too much work to maintain.
  - stephc_int13 4y ago
    Objective-C was/is an awful programming language, one of the worst I ever had the displeasure to work with. But at least they relied on the LLVM toolchain and the NeXTStep heritage, it was possible to use clang and many C APIs and a few wrappers around the horrible Obj-C APIs. With Swift I don't think this will be as practical, if even possible. They are so rich and powerful that they don't care. And most devs on their platforms are happy to drink the kool-aid. This will take time, because they have relatively strong foundations and deep pockets, but they are going to slowly sink their ship, what they are building these days is technically unsound and pretty soon their engineering culture will have completely changed.
  - lukeh 4y ago
    When the last ObjC framework is gone? Surely that’s decades away. There are zillions of frameworks in PrivateFrameworks, many written in ObjC. The Swift/C++ bridging stuff is pretty exciting though. A lot of engineering is being thrown into this.
mark_l_watson 4y ago
Good for Apple. In my opinion they are laying the groundwork for reducing technical debt. Objective-C had a good run. I haven’t used Objective-C in over 10 years but I have used Swift about 10% of the time in the last four years. Swift is a nicely designed language and I could see it supporting Apple’s business for many years. Will Swift ever be a primary language on Linux? I would say yes, except now that Rust is used the advantages of also mixing in Swift are diminished.
- cute_boi 4y ago
  I would recommend people always use language like Rust or C++ instead of swift, so that it is easy to make cross-platform apps. The UI can be made using a native toolkit like swift, gtk, winapi, etc... however, the core engine app should be written in a language like Rust.
  - smoldesu 4y ago
    Swift just isn't mature enough to know for sure, at least on Linux and Windows. With proper optimization, it might make a case for itself on Linux. That being said, it's going nowhere fast without official support from Apple.
  - WFHRenaissance 4y ago
    I bet you would. What color are your programming socks?
runjake 4y ago
Tangental question: How do you Swift-using, non-app developers find out how to do basic anything non-app related, such as reading files and making network connections? I Google for stuff and probably 3/4s of the result are out of date and won't work in any reasonably modern version of Swift. I find Apple's Developer documentation sub-par, to say the least. So, how do you navigate it all? It's quite a shock coming from stuff like Go, C#, and Rust. It'd be pretty cool if there were a good version of the Swift Cookbook Ala the classic Perl Cookbook.
- kstenerud 4y ago
  Apple's documentation is pretty good in this regard. Network comms are generally done using URLSession: https://developer.apple.com/documentation/foundation/urlsession https://developer.apple.com/documentation/foundation/urlsess... Reading files is most often done using the String and Data types: - https://developer.apple.com/documentation/foundation/nsdata/1413892-init https://developer.apple.com/documentation/foundation/nsdata/... - https://developer.apple.com/documentation/swift/string/init(contentsof:encoding https://developer.apple.com/documentation/swift/string/init(...:) I've found Apple's documentation for Foundation to be quite exemplary.
- devmunchies 4y ago
  That’s all part of the lower level foundation library, which is what this post is about. https://developer.apple.com/documentation/foundation/file_system https://developer.apple.com/documentation/foundation/file_sy...
- cvwright 4y ago
  Mostly through sites like hackingwithswift.com Those are generally enough to get you to the point where you can make sense of Apple’s documentation.
- deleted 4y ago
  [deleted]
vbezhenar 4y ago
Does it mean Objective C is going to be second-class language? It would be a pity, I prefer Objective C to Swift.
- miffy900 4y ago
  Seems so. I often wonder what things would be like if Apple had improved upon Objective-C by fixing up the underyling C language. Yeah it'd no longer be a superset of C, but so what? Neither is Swift. Swift is great but I wish it was closer to Objective-C in spirit by deliberately being a more lightweight language. It's language spec is gargantuan - they've pretty much succeeded in making it a language as complex as C++. Merely adding generics and better typing akin to TypeScript's, to Objective-C would've worked wonders and made the transition less abrupt.
  - pjmlp 4y ago
    Not up to date? They already made most of what was possible without breaking compatibility. https://medium.com/ios-os-x-development/generics-in-objective-c-8f54c9cfbce7 https://medium.com/ios-os-x-development/generics-in-objectiv...
- secretsatan 4y ago
  I used to too, it took me a while to switch, but now I see the benefits. Obj-c does give a lot more freedom, and sometimes you still need it, but what initially felt restrictive does actually lead to less buggy and predictable code, and some protocols like codable cut out massive amounts of code. I still rely on some stuff like GCD that isn't very swift like, there still isn't anything as fine grained in Swift, but I'm liking combine in some cases.
  - vbezhenar 4y ago
    My issue with Swift is that it changes faster than I can learn it. I'm not Apple developer, I just write some code for macOS or iOS sometimes, like one time a year. I learned Objective C few years ago and this knowledge is with me. learned Swift 1 but now it's different and it seems that I have to learn it again almost from the scratch. For professional *OS development Swift probably makes sense. But if I occasionally need to write some code, Objective C for me is preferred. May be Swift is stabilized enough already...
jrochkind1 4y ago
Who else remembers when they re-implemented the (at the time version of) the Foundation framework in Java for WebObjects? That was, what, 1998? Right around when NeXT got re-absorbed by Apple, not sure if the rewrite was started before or after. https://developer.apple.com/library/archive/documentation/LegacyTechnologies/WebObjects/WebObjects_5/FoundationRef/Java/JavaFoundation.pdf https://developer.apple.com/library/archive/documentation/Le... https://en.wikibooks.org/wiki/WebObjects/Overview/Objective-C_to_Java_Transition https://en.wikibooks.org/wiki/WebObjects/Overview/Objective-... Those were the days! Actually kind of amazing that the Foundation framework is the result of steady evolution of an ObjC framework written by NeXT... over 30 years ago? All those `NS` prefixes that are still hanging on are for `NextStep`. If this really replaces the ObjC implementation... would that be the final sunset of the codebase that has been there (at least ship of theseus style) from NeXTStep days? I wonder if there's continuous version control history of Foundation source from the start, and how many, if any, lines of code remain from the initial implementation.
- conradev 4y ago
  WebObjects is actually still alive and kicking, but only inside of Apple A lot of the web services that Apple provides still use that implementation of Foundation :)
- deleted 4y ago
  [deleted]
- pvg 4y ago
  Foundation was developed for the needs of EOF so it makes sense there was a version for the Java WebObjects. There's almost certainly NeXT-derived code in macOS/iOS with a longer pedigree and a bunch of it will probably outlast the Foundation rewrite. As software evolution goes, it's an astonishingly long run, no doubt. Especially for a technology that very nearly went extinct.
  - jrochkind1 4y ago
    Huh, Foundation was developed for EOF? (Enterprise Object Framework; it was actually very much like Rails ActiveRecord). I did not realize that, I always figured it came first.
DiabloD3 4y ago
This is pretty alarming. I don't think Apple can do a full rewrite of Foundation, unless its opt-in only for Swift apps that have been ported to the new Swift-only codebase. If they are trying to opt in non-Swift apps, well, I'm glad I don't use OSX nor have to support it. The article linked has few details on how they plan to do this, or how they plan on limiting the blast range.
- deleted 4y ago
  [deleted]
xp84 4y ago
When the product of this hits the OS I predict massive instability. I don't think the Apple of 2022 has the level of systems programming talent that was behind the 1990s code in the core foundation. Today I feel like most of their attempts to move the OS forward beyond the shiny UI gimmicks (Tired of Exposé™? Try Stage Manager!™) are sloppy and only barely work (like "discoveryd" - google that if you don't remember). If you don't believe me, quit all your non-Apple apps, and open up Console.app and hit Start streaming, and limit only to the "Errors and Faults" and watch the computer scream in logs until you're convinced. This is what modern Apple software quality looks like. I really don't want them touching anything near the core OS. Especially because when Apple software doesn't work, either you'll get no feedback, or it will say something comically vague like, that it "can't be completed." I'd LOVE to be proven wrong here because otherwise I'll have to finally catch up on my Windows knowledge and get used to not having a GUI metakey separate from Ctrl!
- nicky0 4y ago
  You say that, but then I counter with the complete reliability and brilliance of Rosetta 2.
- dangus 4y ago
  This is just plain cynicism and dramatization. “Massive instability” lol as if anyone with a desktop OS of any sort in 2023 has had anything close to that kind of experience. Let me know when my scroll bar UI is lagging like it’s 2003 in Cupertino. I’m sure Jaguar had zero errors and had all the code audited by Steve Jobs himself to make sure it had top quality. And for real what indicator is there that Apple has low-talent employees? Do they not pay well with good benefits? Where exactly do you expect all the good systems programmers are working? I don’t think a company with bad low level engineers would be bragging about wake from sleep times in their marketing materials. I don’t know of any other desktop OSes that replaced their entire file system with a routine OTA update transparent to the user. I can think of other big recent changes like how people criticized the new System Settings panel a bunch, but at least Apple didn’t take 10 years of iterative updates to not even finish the transition. Please, someone tell me why Windows 11 still has the old Control Panel when Apple replaced their entire settings panel in a single update. As stupid as it is, in my mind the simple fact that iOS just added a “copy and delete” button to the screenshot capture UI tells me that there are still plenty of power user geeks at Apple. We shouldn’t be surprised that they happen to care about different things than what we cared about in the 90s. We can nitpick the bugs all day but I can’t think of another desktop OS that executes on its goals as consistently as macOS, commercial or not.
alfor 4y ago
Just switched back to windows after a decade with macos. It seem that microsoft care way more about developers at the moment than Apple does. So much good stuff, open source, Linux subsystem, vscode, copilot, documentation, plugins, etc. Things works and are cheap and plentiful. Beside the sleek and high quality hardware, nothing is missing.
- onethought 4y ago
  Linux Subsystem vs BSD Kernel? Everything you listed is on both platforms? What are you actually comparing?
- deleted 4y ago
  [deleted]
pabs3 4y ago
Is the Swift compiler itself written in Swift? How is it bootstrapped from source?
- lukeh 4y ago
  It's written in C++ although there is some Swift in it now [1]. The compiler doesn't depend on Foundation though. [1] https://github.com/apple/swift/tree/main/SwiftCompilerSources https://github.com/apple/swift/tree/main/SwiftCompilerSource...
ribit 4y ago
It looks like an important step in progressively retiring ObjC. Swift is built from the start with a ObC compatibility in mind, which is a source of much ugliness and inefficiency in the language. With the Swift team working in a value semantic first language (Val), I can kind of see where this is going. Really looking forward to OOP being phased out.
- flohofwoe 4y ago
  > Really looking forward to OOP being phased out. All the higher level macOS APIs are still object oriented, and I don't see that changing TBH. And macOS application source code is essentially just minimal glue code to tie those system APIs together, in the end, the programming language used for this glue code doesn't matter all that much, since the code is completely dominated by API calls.
  - ribit 4y ago
    Cocoa is object-oriented, but modern APIs not so much. They are of course based on interfaces/traits/protocols (whatever you want to call them) but it’s not the same as 90ies style inheritance-based OOP. It’s the inheritance as basis for behavior is what I want to see gone. But even Cocoa already embraces composition more than inheritance.
- pjmlp 4y ago
  Given that all modern language support most OOP concepts, phasing out is not happening any time soon.
  - ribit 4y ago
    By OOP I mean entangling of behavior and type hierarchy (mainstream class-based OOP aka. C++ OOP). Dot-notation and methods do not equate OOP. But of course, it depends on your definition. Pretty much anything can be called “OOP” if one wants to.
    - pjmlp 4y ago
deleted 4y ago
[deleted]
up2isomorphism 4y ago
Every time like this, bunch of people who believe safe programming is a language capability will jump out. But in fact, the most valuable part of the code in any nontrivial system is the “unsafe” yet safe ones. You write memory safe code by understanding how computers memory works, sometimes you can use certain patterns to make that process easier, but not always. This is regardless what language you use: you programming in Rust, still the most valuable part is where one can get the “unsafe” part right. A good C programmer will always a better Rust programmer when he wants to. That’s it.

434 points by frizlab 4y ago

leo150 4y ago

Wait, no more "po [$arg1 reason]"?

Bud 4y ago

[dead]

wlesieutre 4y ago

Similar post by Michael Tsai with some quick summary points of the impact of this: https://mjtsai.com/blog/2022/12/12/the-swifty-future-of-foundation/ https://mjtsai.com/blog/2022/12/12/the-swifty-future-of-foun...

ofcourseyoudo 4y ago
Thanks for that, always appreciaet Tsai's perspective and this part stuck out to me: >it sounds like the plan is to rewrite it in Swift and extend Swift to allow Objective-C to call the Swift implementation of the old API
- phillco 4y ago
  I really like his style of 1) summarising articles he links to 2) attaching follow up from elsewhere on the internet, it's a nice pattern I'm surprised hasn't been more widely copied
xenadu02 4y ago
Not sure why but most people don't seem to have noticed that people outside Apple will now be able to contribute to Foundation and these contributions will ship across all platforms.
- lapcat 4y ago
  Free labor for the world's most profitable corporation. Looking forward to it. And then they still take a cut of your revenue.
  - sunshinerag 4y ago
    You also mean “paid labour From the worlds most profitable corporation” right?
    - lapcat 4y ago
      No?

the_solenoid 4y ago

Todd, you owe me $20. (Todd said this would never happen) Also, this is great news, and it will be interesting to see what kind of real-world changes in performance this has.

mpweiher 4y ago
Things will get even slower.
- zuhsetaqi 4y ago
  Why do you think it’ll be slower? The article says the opposite
- KerrAvon 4y ago
  Available data so far seems to show that the pure Swift implementations are faster than the Objective-C ones even when called from ObjC clients. I don't have a link, so feel free to treat as hearsay, but FYI.
  - mpweiher 4y ago
    You don't have a link to the data because this is not true. Swift is generally slower than Objective-C, often significantly so. There are cases where it is faster, but those are rare. Yes, I have measured. One example is JSON and Swift codable, which is comically slow, see: Somewhat Less Lethargic JSON Support for iOS/macOS, Part 1: The Status Quo https://blog.metaobject.com/2020/04/somewhat-less-lethargic-json-support.html https://blog.metaobject.com/2020/04/somewhat-less-lethargic-... Punch line: Swift codable does around 10MB/s, despite all the supposed performance goodies and compiler support everyone always talks about and nobody appears to ever measure. A pure Objective-C implementation does 284MB/s. I also did a more general survey for my book[1]. While that's been a while, I haven't seen any indication that things have fundamentally changed, and lots of indications that they haven't.
    - astrange 4y ago

hyperhello 4y ago

“A reimplementation of Calendar in Swift is 1.5x to 18x as fast as the C one (calling from Swift in various synthetic benchmarks like creation, date calculation).” I’m sure it is, but this is not solving the right problem at all. Calendar is all UI. It needs to be lovingly gone over, not this.

stephencanon 4y ago
That quote is talking about the Foundation type named Calendar (https://developer.apple.com/documentation/foundation/calendar https://developer.apple.com/documentation/foundation/calenda...), not Calendar.app.
newZWhoDis 4y ago
Calendar/Date is the foundation for all time handling in iOS apps. If you see a string with a date in it it was probably handled by this system.
jeremy_wiebe 4y ago
This post is referring to NSCalendar and Swift's Calendar class. > NSCalendar objects encapsulate information about systems of reckoning time in which the beginning, length, and divisions of a year are defined. > The Swift overlay to the Foundation framework provides the Calendar structure, which bridges to the NSCalendar class. https://developer.apple.com/documentation/foundation/nscalendar https://developer.apple.com/documentation/foundation/nscalen...
mpweiher 4y ago
Note the somewhat disingenuous performance claim: The reimplementation itself is not 1.5x to 18x as fast as the C one. It is calling from Swift that is faster. Yes, they correct in the parenthesis, but that's not how parenthetical expressions work: A parenthetical expression is extra information added to a sentence or question that clarifies, explains, or adds information without changing the basic meaning. Think of it as an aside providing readers with helpful information that they don’t absolutely have to have, but that is helpful to them. https://grammar.yourdictionary.com/style-and-usage/parenthetical-expression-types-and-usage.html https://grammar.yourdictionary.com/style-and-usage/parenthet... So basically, they are fixing the problem they've been having with bridging performance, which of course is due purely to them mis-designing Swift in such a way that it doesn't bridge well with all the existing code they have.

justinator 4y ago

[flagged]

gl-prod 4y ago
anyways

eatonphil 4y ago

I don't know Swift too well but my impression is that the support on Linux within the Foundation is not complete. (Also, is Foundation the same thing as what one might normally term a standard library? I can't tell.) Does this change imply better (eventual) support on non-Darwin systems? Or maybe I've misread it and the change is unrelated.

mplewis9z 4y ago
> my impression is that the support on Linux within the Foundation is not complete It is not, but it's like 95% of the way there in my experience - most things that are missing are relatively recent additions that have some complex OS interactions, like filesystem I/O with language-level concurrency features. > Does this change imply better (eventual) support on non-Darwin systems? Yes. The non-Darwin Foundation version is already rewrite that takes a lot of effort to keep in lock-step with the closed-source Objective-C version, so unifying the implementations in Swift will both reduce the amount of maintenance effort and promote non-Darwin platorms to more of a "first-party" status. > Also, is Foundation the same thing as what one might normally term a standard library? It's more of a standard library++, including some things that other languages include in their standard libraries (Date/Time models) but also other things that are common to put in third-party libraries (networking, etc.). You do not need to use Foundation for basic things like arrays or concurrency that are built into the normal standard library.
- eatonphil 4y ago
  > complex OS interactions, like filesystem I/O with language-level concurrency features. Do you mean like io_uring? That wouldn't be too surprising. Even Go doesn't have that in the standard library yet. > so unifying the implementations in Swift will both reduce the amount of maintenance effort and promote non-Darwin platorms to more of a "first-party" status. That's what I was hoping for. Thanks!
- avisser 4y ago
  <bikeshed> It feels off to call things like Array part of any library when you have array literal syntax `let oddNumbers = [1, 3, 5, 7, 9, 11, 13, 15]` I'd call that a language feature. Or maybe with Swift there is a blurry line between the two?

KingLancelot 4y ago

9 years after the created this language they’re only now beginning to do this?

deleted 4y ago
[deleted]

dcow 4y ago

I am pretty certain that most of high level use cases for Rust could be replaced with Swift, with increased developer velocity, if Swift was actually cross platform. And that's coming from a Rust fan. It will be interesting to see how effective this rewrite is.

kitsunesoba 4y ago
I would love to be able to write cross-platform desktops apps in Swift. The language isn't perfect of course but I enjoy it a lot more than the alternatives I've tried. That possibility is still a ways down the road of course but Foundation getting a cross platform rewrite is a nice step in that direction.
- rattray 4y ago
  If you or others on this thread are interested in working on a Swift compiler for Windows, please reach out to me :) a good friend is hiring a team to make this happen.
  - Someone 4y ago
    How will that be different from Apple’s Swift toolchain for Windows (https://www.swift.org/blog/swift-on-windows/ https://www.swift.org/blog/swift-on-windows/)?
    - rattray 4y ago
      https://youtu.be/bOMQiMxh5Bc?t=430 https://youtu.be/bOMQiMxh5Bc?t=430 relevant listen is about 2min long
      - Someone 4y ago
        To me, that sounds as if most of the work would not be on the compiler but on improving the development experience (IDE, debugging support). On the other hand, your comment said ”working on _a_ Swift compiler for Windows”. To me, that sounded like a new compiler, not adding missing features to the existing one. Which of the two is it?

deleted 4y ago

[deleted]

pvg 4y ago

Very short discussion last month: https://news.ycombinator.com/item?id=33923484 https://news.ycombinator.com/item?id=33923484

ChrisMarshallNY 4y ago

This will take a while, but I'm looking forward to it. It's probably another big step towards "Swift everywhere," without worrying about bridging to C. I've been doing little but Swift since 2014, and really like the language. I'm still "on the fence" about SwiftUI, but that's mostly because of the level of support from Apple, and the [im]maturity of the system. This will help with that.

manmal 4y ago
Yes, and it means Swift scripts and modules that don’t reference UIKit/AppKit/SwiftUI/Combine will run on Linux and possibly Windows with zero or little modification. I‘m a little sad though that they didn’t start this endeavor years ago, because IMO Rust has already built so much momentum that it will win (for the popular, medium to long term definition of „winning“).
- ChrisMarshallNY 4y ago
  I don't particularly care, whether or not Swift ever leaves the Apple ecosystem (like ObjC). In that domain, Rust will never "win." I think that Rust is an awesome server language, though, and I'm glad to see it gain traction. I just hope that it doesn't get trashed by a bunch of junk dependencies, written in it. I find using apps written, using hybrid systems, or PWAs, to be quite painful (on Apple devices -and that includes that awful JS TVOS system), so I am a big proponent of real native apps.
  - manmal 4y ago
    I think whoever „wins“, it would be necessary to have good interop at least. Currently, Rust devs are integrating core libs into native iOS apps by going the C route. All this work to make everything memory safe, and then this.
    - mrtesthah 4y ago
      Swift-based interop would provide richer type information. See how swift-bridge takes advantage of it: https://github.com/chinedufn/swift-bridge https://github.com/chinedufn/swift-bridge

birdymcbird 4y ago

Someone knowing existing pattern help me understand this. right now when i use these “foundation” apis in swift it is doing c call? so they rewriting now the c code in swift? (dont do ios or mac code so now sure) me dont understand what make it faster now. i once wrote some jni code to call c++ library from java. does mean there some similar code to do cross language call? they get rid of it and so things now faster? offtopic but debugging crashes in c++ over jni call was super hard. logs not work and me not figure out how to fix. wonder if they had similar “troubles” and this make everything easier :) always feel skeptical when seeing large code base have “rewrite”. try many time in me career thinking there good reasons but super hard and not best value in end

machinekob 4y ago
It's a lot of obj-c/c on apple and syscalls on other platforms, I think the biggest point its to get rid of annoying obj-c calls and make it fully cross platform as its a nightmare for both safety and performance in many cases to call objc.
saagarjha 4y ago
Most of Foundation on Darwin used to call into Objective-C code. This is going to be replaced with Swift code while keeping the API the same.
- Reason077 4y ago
  Conversely, will existing Obj-C (and hybrid Swift/Obj-C) apps be able to call the new Swift Foundation? And will it be binary-compatible with existing apps, or will Apple just ship a separate compatibility version of Foundation for use by legacy apps?
  - saagarjha 4y ago
    Yes, it’ll be binary compatible.
    - 4y ago

alberth 4y ago

What remaining Apple frameworks are not yet written in Swift?

saagarjha 4y ago
Most of them. Very few frameworks are actually written primarily in Swift.
- alberth 4y ago
  Would the macOS kernel (Mach) ever be rewritten in Swift? And if so, what benefit would it provide?
  - deleted 4y ago
    [deleted]
  - mplewis9z 4y ago
    I doubt the entire kernel would - there are low-level, memory-unsafe operations that an operating system performs that Swift _could_ do, but it would be fighting the design of the language and likely not a great trade-off for the kernel developers. But pieces absolutely could be. The benefit would be compile-time checking for memory safety issues (reducing crashes) and language-level concurrency (fewer race conditions and a much easier path to parallelize single-threaded code for performance).
    - MBCook 4y ago
      I believe all the code on the Secure Enclave is now Swift. I believe they use a special mode/analyzers to ensure only the “ok” stuff is used. Perhaps no memory allocation, for example. It sounds to me like Apple would like Swift, perhaps with some extra tooling, to be able to handle the Mach kernel. I don’t know if they’ll go that far though.
      - saagarjha 4y ago
        Definitely not, it’s just used for some parts.

davidkuennen 4y ago

Apple has such an unpredictable stance on software development. For example after all these years and lots of requests for such a feature it's still not possible to get notified about new reviews for your apps, but it's possible to get notified when a user edits a review after you've replied to it.

deleted 4y ago
[deleted]
rufius 4y ago
Apple’s style reminds me a lot of something I once read (and later experienced) about Japan and tourism: > (roughly) Japan is a country for the Japanese. While they may welcome you and invite you to experience their country and culture, the country is very much setup to serve the Japanese populace. Apple feels similarly. They build what they need and enough to capture the revenue they want, but I don’t perceive them to really cater to external needs beyond what will monetize.
- threeseed 4y ago
  > but I don’t perceive them to really cater to external needs beyond what will monetize So then why does all of Apple's operating systems and apps receive updates at all. Your argument is completely illogical.
j-f1 4y ago
I’m not sure about macOS, but on iOS you can install the App Store Connect app (https://apps.apple.com/app/id1234793120 https://apps.apple.com/app/id1234793120) and then enable notifications for new reviews from there. ([app] → Notifications → Mobile → Reviews, [your initials] → Notifications → Customer Reviews)

psmyrdek 4y ago

How prospective it is to jump on the iOS bandwagon in 2023?

deleted 4y ago
[deleted]
emehex 4y ago
Learning iOS (Swift) could be a gateway to the next-generation of platforms: carOS, realityOS (AR/VR). Or both of these efforts could be complete duds!

meitham 4y ago

Could someone please explain what exactly is the “Foundation”?

oneplane 4y ago
It's the base framework where types like NSObject, NSString, NSDictionary etc. are defined. It's right there in the article. It also explains why it exists, what others exist, and what a rewrite will bring.
KyeRussell 4y ago
It’s not respectful to not read the link and instead ask somebody to summarise it for you.
- meitham 4y ago
  You’re making the wrong assumption! I have read the article before I asked, and still have no idea what it is! Saying it provides these abstraction NSObject, NSString, NSArray tells me nothing! The article is clearly written towards readers familiar with Apple ecosystem.
  - herodotus 4y ago
    Objective-C is an object-oriented programming language that is essentially a super-set of C. In fact the earliest implementation of Objective C, if I recall correctly, translated Objective-C code to C. The only built in types in Objective-C are the C types, like int, char and so on. The "Foundation" is a set of classes that implement many useful types that all inherit from a superclass called NSObject. The "NS" prefix refers to Next Step, the name of the company that Steve Jobs started and where Foundation was first created. One of the advantages of this scheme is that it is possible to have heterogeneous collections (like an array of objects, where the objects do not all have to be of the same type/class). Underneath the NS foundation (whose headers are all in Objective-C) is something called Core Foundation, which implements the same classes, but in pure C. To do this well requires huge programming discipline, especially around memory management, and much of that pain is taken away by using the NS classes. Swift has already started replacing some of the foundation classes, NSString and NSDictionary, for example, giving them the names String and Dictionary without the cumbersome name-space two letter prefix. I suspect that some of this rewrite may still "bridge" to the CF classes, but in other cases, it would be much better to simply write the class in its entirety in Swift. I hope that helps.

macinjosh 4y ago

I was in a line once at WWDC in 2011. I happened to be in front of a group of Apple engineers. I overheard them discussing a rumored functional-ish language that Apple was to switch to from Obj-C. They didn't know what it was but they seemed skeptical that it would ever be put into real use. Glad to see it only took 11 years for it to permeate down to the Foundation framework. :)

whimsicalism 4y ago
Seems generous to describe as functional language, but I guess if you're coming from Obj-C...
deleted 4y ago
[deleted]

andrewmcwatters 4y ago

> A reimplementation of Calendar in Swift is 1.5x to 18x as fast as the C one (calling from Swift in various synthetic benchmarks like creation, date calculation). These sorts of statements in the industry always make me ask, "So did you guys make something terribly slow first, and then bring performance back close to where it originally was?" I'm not sure if the current Calendar app was ported to Swift, was originally Objective-C based, and such efforts to move Foundation to Swift will just... make Calendar fast again? Also, Calendar doesn't seem to be particularly slow in the first place. But I love performance engineering, and quality of life is big, so... hey cool.

MBCook 4y ago
They’re not talking about the app. They’re talking about the Calendar class in Foundation.
munificent 4y ago
> "So did you guys make something terribly slow first, and then bring performance back close to where it originally was?" In this case, the answer is basically, "yes". Objective-C is a neat language and really powerful in terms of flexibility and extensibility. But it gets that by essentially dynamically typed. It's Smalltalk duct taped onto C. Dynamically typed languages are much slower unless you do lots of very powerful JIT magic, and even then they still tend to be quite a bit slower than most statically typed compiled languages. Building Swift on top of an Objective-C core library makes a lot of sense in terms of getting Swift adoption when Swift was new. But in terms of performance, it's sort of like building a concrete bunker on top of a straw hut. You really want the bottom of your stack to be the faster, statically typed language. Then you can layer dynamic scripting languages on top for the users who want it.

bfrog 4y ago

So apple seems to be dropping c like languages, Microsoft says new stuff should not be written in c like languages anymore, and google has steadily worked towards using rust and go in place of c and c++ where it makes sense to do so it seems. There seems to be a trend here.

phpisthebest 4y ago
>>Microsoft says new stuff should not be written in c like languages anymore Microsoft is dropping C#? Source for that?
- bfrog 4y ago
  C# is a lot closer to Java if anything, should clarify to be c and c++
- mplewis9z 4y ago
  Calling C# a C-like language is like saying JavaScript is a descendant of Java.
- AppleBananaPie 4y ago
  could be worded better but from context in the sentence I read that as c/c++
- jon-wood 4y ago
  I think the GP probably poorly phrased that. “Memory unsafe languages” would be a better term, apart from the basic syntax C# really isn’t very C-like.
- ccouzens 4y ago
  Based on the context I think by "c like" they meant languages with a culture of dealing with raw pointers. c# is c by name and curly braces, but primarily uses managed memory
- diroussel 4y ago
  C# is not a C-like language. It's a managed runtime with garbage collection. However Mark Russinovich, CTO of Azure did say that it's time to drop C and C++ https://twitter.com/markrussinovich/status/1571995117233504257 https://twitter.com/markrussinovich/status/15719951172335042...

w10-1 4y ago

Correction: rewrite of PARTS of Foundation There already was an open-source project to rewrite ALL of foundation, but it had stalled on the shores of having to re-implement everything: https://github.com/apple/swift-corelibs-foundation The news is actually that Apple is now instead trying to define the bits/parts to support via Swift on all platforms (the original API's will always be supported on Darwin). The announcement: https://www.swift.org/blog/future-of-foundation/ The discussion, with hairy details about which bits, esp. for async: https://forums.swift.org/t/what-s-next-for-foundation/61939/103 The plan is to divide up Foundation into more- and less-essential parts, to get more-essential parts locked down so people can rely on them. What's Foundation? Swift's most-core library is the stdlib, tightly coupled to the compiler/language version, providing things like arrays, dictionary, etc., and available wherever Swift is. Beyond that, Foundation is the library with core API's for common features, e.g., for dates and concurrency. Stdlib is fully cross-platform and Swift-specific, but Foundation is a beast with API's dating to NExT with support for 20 years of API's. Microsoft famously arrived at porridge for an operating system by maintaining backwards compatibility. Apple has cracked open Swift by developing in the open, but it's still Apple-funded and Apple-driven. Library and some integration support for other platforms has always had to come from community (notably compnerd's heroic effort to make-things-work on windows, and a revolving cast wanting Linux support for their server API's). But there's no good reason to impose the whole Foundation history on other platforms. And there may be a movement inside Apple to migrate internal code to newer async API's, designed after the recent Apple-silicon generation. For developers with server experience and some free time in a tech lull, it could be a good opportunity to help rebuild a new, er, foundation for computing on all devices, that's native but type- and memory-safe. The community is large and mature, but there is plenty of room for others.

deleted 4y ago
[deleted]
smoldesu 4y ago
It simply sounds like there isn't much demand for Swift from the Open Source community. Apple certainly makes a big push for it internally, but outside their platform, Swift doesn't have much momentum. If Apple wants people to use Swift like a first-class runtime, they should stop treating third-parties like second-class citizens. They have $200 billion dollars in cold, hard cash - surely some of it could go towards the selfless development of a universal future computing platform, right?

Gigachad 4y ago

The removal of C from Android and iOS is going to pay off massively. The current state of things where every government is sitting on an endless collection of exploits is not ideal.

smoldesu 4y ago
Considering that both Google and Apple are cardholding members of PRISM, it sounds like a bit of a frying pan vs fire situation to me.
- typon 4y ago
  Yes, but that's OUR surveillance and we're cool with that
  - sbaiddn 4y ago
    Id rather be spied on by foreigners who couldn't do anything about my eccentricities even if they cared. When you're own government's security services are spying on you, they own you.
    - Gigachad 4y ago
      The options weren't foreign government or local government, the current state is both, the future is local only. It's clearly an improvement. These security exploits also get used by local police who wouldn't have access to the top government access used for terrorists.
      - deleted 4y ago
        [deleted]
      - deleted 4y ago
        [deleted]
      - deleted 4y ago
        [deleted]

Octokiddie 4y ago

The article quotes this: > With a native Swift implementation of Foundation, the framework no longer pays conversion costs between C and Swift, resulting in faster performance. and this: > A reimplementation of Calendar in Swift is 1.5x to 18x as fast as the C one (calling from Swift in various synthetic benchmarks like creation, date calculation). First, that range of 1.5x-18x is kind of huge. Why? Second, why would the intro with C be such a big performance penalty even assuming it's just 1.5x? I know there must be an overhead, but why so large? Also, why single out the Calendar? Is it somehow representative?

dvh 4y ago
I know nothing about their c codebase but I assume it's because when the language is hard, you tend to keep it as simple as possible. When every line stops being a foot gun, you start using optimizations you wouldn't dare before.
- bborud 4y ago
  That's a plausible explanation which I find to have support in personal experience.
vkou 4y ago
More importantly, why single out something like date calculation? Does that really eat a meaningful number of CPU cycles that needs to be optimized?
haimez 4y ago
I’m not deeply familiar with swift, objective-C or the next-step APIs, but it seems like they’re describing the difference between a (virtual?) function call (ie: swift to swift) vs a “message passing operation” in objective C. If that assessment is correct, then it’s really an exercise in small costs adding up quickly. If you call through the function pointer you have way lower latency, and if you call through the same operation hundreds of times to render a single screen (the calendar) inside of the render loop where latency matters- that’s measurably better. Especially on a device that tries to throttle CPU frequency to save battery power. This is somewhat analogous to the same arguments that can be had about JIT compiled languages having the the opportunity to exceed performance of AoT compiled ones because of inlining opportunities- except in this case I don’t know if the call has any chance of being actually inlined so much as at least bypassing the message passing machinery overhead.

singularity2001 4y ago

It makes me so sad that swift, a compiled language more beautiful than Rust IMO, has such inferior support outside the Apple garden.

deleted 4y ago
[deleted]

thrwawy74 4y ago

Is there anything genuinely innovative about Swift or is it just another "cross-platform scripting language" that I'll only see on 1 platform? The only reason I learned Powershell is because I have to admin for Windows. At least Powershell is interesting for its pipeline and object handling. I get not one spark of joy from Swift, and the comments I see are "at least we're not writing C anymore". Stockholm syndrome. Sorry this is so negative, but I can't get excited about $NewLanguage unless I know it offers real benefit. I have drunk the Rust koolaid, and for very good reasons. What am I missing in Swift?

yw3410 4y ago
If I recall Swift has a very interesting ABI for generics. 1. https://faultlore.com/blah/swift-abi/ https://faultlore.com/blah/swift-abi/
- thrwawy74 4y ago
  I appreciated this comment. This is something I hadn't seen :-)
lloydatkinson 4y ago
I've never done any Mac or iOS development and even I can see this is a strange question. I don't know why you think it's a scripting language, or how it compares in anyway to powershell?
nolimitsky 4y ago
[flagged]
deleted 4y ago
[deleted]
mrtksn 4y ago
It’s pleasant to use, that’s the main thing about Swift. A very Apple thing to be honest, so just like most of the Apple products it’s very good in few thing and good enough in others and probably nothing is completely new. The overall experience is pleasant. Apple is building just as pleasant tooling around it, Swift Playgrounds is amazing for example. Newbies can learn coding by doing some exercises disguised as games but that’s not what’s amazing, what’s amazing is that you can make full apps with all the libraries and Swift packages and SwiftUI. Apple did good job hiding the boilerplate away, did good job removing the decision making about the project file structure and created an intuitive interface where you can just code without worrying about anything else. In 2020s, Swift is probably the only language with tooling that lets you just code your ideas and deploy without dealing with anything else. Like creating a Word document and writing your thoughts down straightforward. I don’t know if submitting from Swift Playgrounds to the AppStore has been released but the beta I was trying last month had this functionality. From idea to market, start to finish integration.

stephc_int13 4y ago

This is an other step in the direction to a Swift-only Apple platforms. I don't think it would be worth my time to even buy a other macOS device to port my framework. I don't think they will get any benefit from this.

musicale 4y ago
It's a good question as to how long Apple will support calling its APIs from C++ via Objective-C++. I don't see any good reason for them to deprecate the ObjC-Swift bridge, but I guess they could decide it's too much work to maintain.
- stephc_int13 4y ago
  Objective-C was/is an awful programming language, one of the worst I ever had the displeasure to work with. But at least they relied on the LLVM toolchain and the NeXTStep heritage, it was possible to use clang and many C APIs and a few wrappers around the horrible Obj-C APIs. With Swift I don't think this will be as practical, if even possible. They are so rich and powerful that they don't care. And most devs on their platforms are happy to drink the kool-aid. This will take time, because they have relatively strong foundations and deep pockets, but they are going to slowly sink their ship, what they are building these days is technically unsound and pretty soon their engineering culture will have completely changed.
- lukeh 4y ago
  When the last ObjC framework is gone? Surely that’s decades away. There are zillions of frameworks in PrivateFrameworks, many written in ObjC. The Swift/C++ bridging stuff is pretty exciting though. A lot of engineering is being thrown into this.

mark_l_watson 4y ago

Good for Apple. In my opinion they are laying the groundwork for reducing technical debt. Objective-C had a good run. I haven’t used Objective-C in over 10 years but I have used Swift about 10% of the time in the last four years. Swift is a nicely designed language and I could see it supporting Apple’s business for many years. Will Swift ever be a primary language on Linux? I would say yes, except now that Rust is used the advantages of also mixing in Swift are diminished.

cute_boi 4y ago
I would recommend people always use language like Rust or C++ instead of swift, so that it is easy to make cross-platform apps. The UI can be made using a native toolkit like swift, gtk, winapi, etc... however, the core engine app should be written in a language like Rust.
- smoldesu 4y ago
  Swift just isn't mature enough to know for sure, at least on Linux and Windows. With proper optimization, it might make a case for itself on Linux. That being said, it's going nowhere fast without official support from Apple.
- WFHRenaissance 4y ago
  I bet you would. What color are your programming socks?

runjake 4y ago

Tangental question: How do you Swift-using, non-app developers find out how to do basic anything non-app related, such as reading files and making network connections? I Google for stuff and probably 3/4s of the result are out of date and won't work in any reasonably modern version of Swift. I find Apple's Developer documentation sub-par, to say the least. So, how do you navigate it all? It's quite a shock coming from stuff like Go, C#, and Rust. It'd be pretty cool if there were a good version of the Swift Cookbook Ala the classic Perl Cookbook.

kstenerud 4y ago
Apple's documentation is pretty good in this regard. Network comms are generally done using URLSession: https://developer.apple.com/documentation/foundation/urlsession https://developer.apple.com/documentation/foundation/urlsess... Reading files is most often done using the String and Data types: - https://developer.apple.com/documentation/foundation/nsdata/1413892-init https://developer.apple.com/documentation/foundation/nsdata/... - https://developer.apple.com/documentation/swift/string/init(contentsof:encoding https://developer.apple.com/documentation/swift/string/init(...:) I've found Apple's documentation for Foundation to be quite exemplary.
devmunchies 4y ago
That’s all part of the lower level foundation library, which is what this post is about. https://developer.apple.com/documentation/foundation/file_system https://developer.apple.com/documentation/foundation/file_sy...
cvwright 4y ago
Mostly through sites like hackingwithswift.com Those are generally enough to get you to the point where you can make sense of Apple’s documentation.
deleted 4y ago
[deleted]

vbezhenar 4y ago

Does it mean Objective C is going to be second-class language? It would be a pity, I prefer Objective C to Swift.

miffy900 4y ago
Seems so. I often wonder what things would be like if Apple had improved upon Objective-C by fixing up the underyling C language. Yeah it'd no longer be a superset of C, but so what? Neither is Swift. Swift is great but I wish it was closer to Objective-C in spirit by deliberately being a more lightweight language. It's language spec is gargantuan - they've pretty much succeeded in making it a language as complex as C++. Merely adding generics and better typing akin to TypeScript's, to Objective-C would've worked wonders and made the transition less abrupt.
- pjmlp 4y ago
  Not up to date? They already made most of what was possible without breaking compatibility. https://medium.com/ios-os-x-development/generics-in-objective-c-8f54c9cfbce7 https://medium.com/ios-os-x-development/generics-in-objectiv...
secretsatan 4y ago
I used to too, it took me a while to switch, but now I see the benefits. Obj-c does give a lot more freedom, and sometimes you still need it, but what initially felt restrictive does actually lead to less buggy and predictable code, and some protocols like codable cut out massive amounts of code. I still rely on some stuff like GCD that isn't very swift like, there still isn't anything as fine grained in Swift, but I'm liking combine in some cases.
- vbezhenar 4y ago
  My issue with Swift is that it changes faster than I can learn it. I'm not Apple developer, I just write some code for macOS or iOS sometimes, like one time a year. I learned Objective C few years ago and this knowledge is with me. learned Swift 1 but now it's different and it seems that I have to learn it again almost from the scratch. For professional *OS development Swift probably makes sense. But if I occasionally need to write some code, Objective C for me is preferred. May be Swift is stabilized enough already...

jrochkind1 4y ago

Who else remembers when they re-implemented the (at the time version of) the Foundation framework in Java for WebObjects? That was, what, 1998? Right around when NeXT got re-absorbed by Apple, not sure if the rewrite was started before or after. https://developer.apple.com/library/archive/documentation/LegacyTechnologies/WebObjects/WebObjects_5/FoundationRef/Java/JavaFoundation.pdf https://developer.apple.com/library/archive/documentation/Le... https://en.wikibooks.org/wiki/WebObjects/Overview/Objective-C_to_Java_Transition https://en.wikibooks.org/wiki/WebObjects/Overview/Objective-... Those were the days! Actually kind of amazing that the Foundation framework is the result of steady evolution of an ObjC framework written by NeXT... over 30 years ago? All those `NS` prefixes that are still hanging on are for `NextStep`. If this really replaces the ObjC implementation... would that be the final sunset of the codebase that has been there (at least ship of theseus style) from NeXTStep days? I wonder if there's continuous version control history of Foundation source from the start, and how many, if any, lines of code remain from the initial implementation.

conradev 4y ago
WebObjects is actually still alive and kicking, but only inside of Apple A lot of the web services that Apple provides still use that implementation of Foundation :)
deleted 4y ago
[deleted]
pvg 4y ago
Foundation was developed for the needs of EOF so it makes sense there was a version for the Java WebObjects. There's almost certainly NeXT-derived code in macOS/iOS with a longer pedigree and a bunch of it will probably outlast the Foundation rewrite. As software evolution goes, it's an astonishingly long run, no doubt. Especially for a technology that very nearly went extinct.
- jrochkind1 4y ago
  Huh, Foundation was developed for EOF? (Enterprise Object Framework; it was actually very much like Rails ActiveRecord). I did not realize that, I always figured it came first.

DiabloD3 4y ago

This is pretty alarming. I don't think Apple can do a full rewrite of Foundation, unless its opt-in only for Swift apps that have been ported to the new Swift-only codebase. If they are trying to opt in non-Swift apps, well, I'm glad I don't use OSX nor have to support it. The article linked has few details on how they plan to do this, or how they plan on limiting the blast range.

deleted 4y ago
[deleted]

xp84 4y ago

When the product of this hits the OS I predict massive instability. I don't think the Apple of 2022 has the level of systems programming talent that was behind the 1990s code in the core foundation. Today I feel like most of their attempts to move the OS forward beyond the shiny UI gimmicks (Tired of Exposé™? Try Stage Manager!™) are sloppy and only barely work (like "discoveryd" - google that if you don't remember). If you don't believe me, quit all your non-Apple apps, and open up Console.app and hit Start streaming, and limit only to the "Errors and Faults" and watch the computer scream in logs until you're convinced. This is what modern Apple software quality looks like. I really don't want them touching anything near the core OS. Especially because when Apple software doesn't work, either you'll get no feedback, or it will say something comically vague like, that it "can't be completed." I'd LOVE to be proven wrong here because otherwise I'll have to finally catch up on my Windows knowledge and get used to not having a GUI metakey separate from Ctrl!

nicky0 4y ago
You say that, but then I counter with the complete reliability and brilliance of Rosetta 2.
dangus 4y ago
This is just plain cynicism and dramatization. “Massive instability” lol as if anyone with a desktop OS of any sort in 2023 has had anything close to that kind of experience. Let me know when my scroll bar UI is lagging like it’s 2003 in Cupertino. I’m sure Jaguar had zero errors and had all the code audited by Steve Jobs himself to make sure it had top quality. And for real what indicator is there that Apple has low-talent employees? Do they not pay well with good benefits? Where exactly do you expect all the good systems programmers are working? I don’t think a company with bad low level engineers would be bragging about wake from sleep times in their marketing materials. I don’t know of any other desktop OSes that replaced their entire file system with a routine OTA update transparent to the user. I can think of other big recent changes like how people criticized the new System Settings panel a bunch, but at least Apple didn’t take 10 years of iterative updates to not even finish the transition. Please, someone tell me why Windows 11 still has the old Control Panel when Apple replaced their entire settings panel in a single update. As stupid as it is, in my mind the simple fact that iOS just added a “copy and delete” button to the screenshot capture UI tells me that there are still plenty of power user geeks at Apple. We shouldn’t be surprised that they happen to care about different things than what we cared about in the 90s. We can nitpick the bugs all day but I can’t think of another desktop OS that executes on its goals as consistently as macOS, commercial or not.

alfor 4y ago

Just switched back to windows after a decade with macos. It seem that microsoft care way more about developers at the moment than Apple does. So much good stuff, open source, Linux subsystem, vscode, copilot, documentation, plugins, etc. Things works and are cheap and plentiful. Beside the sleek and high quality hardware, nothing is missing.

onethought 4y ago
Linux Subsystem vs BSD Kernel? Everything you listed is on both platforms? What are you actually comparing?
deleted 4y ago
[deleted]

pabs3 4y ago

Is the Swift compiler itself written in Swift? How is it bootstrapped from source?

lukeh 4y ago
It's written in C++ although there is some Swift in it now [1]. The compiler doesn't depend on Foundation though. [1] https://github.com/apple/swift/tree/main/SwiftCompilerSources https://github.com/apple/swift/tree/main/SwiftCompilerSource...

ribit 4y ago

It looks like an important step in progressively retiring ObjC. Swift is built from the start with a ObC compatibility in mind, which is a source of much ugliness and inefficiency in the language. With the Swift team working in a value semantic first language (Val), I can kind of see where this is going. Really looking forward to OOP being phased out.

flohofwoe 4y ago
> Really looking forward to OOP being phased out. All the higher level macOS APIs are still object oriented, and I don't see that changing TBH. And macOS application source code is essentially just minimal glue code to tie those system APIs together, in the end, the programming language used for this glue code doesn't matter all that much, since the code is completely dominated by API calls.
- ribit 4y ago
  Cocoa is object-oriented, but modern APIs not so much. They are of course based on interfaces/traits/protocols (whatever you want to call them) but it’s not the same as 90ies style inheritance-based OOP. It’s the inheritance as basis for behavior is what I want to see gone. But even Cocoa already embraces composition more than inheritance.
pjmlp 4y ago
Given that all modern language support most OOP concepts, phasing out is not happening any time soon.
- ribit 4y ago
  By OOP I mean entangling of behavior and type hierarchy (mainstream class-based OOP aka. C++ OOP). Dot-notation and methods do not equate OOP. But of course, it depends on your definition. Pretty much anything can be called “OOP” if one wants to.
  - pjmlp 4y ago

deleted 4y ago

[deleted]

up2isomorphism 4y ago

Every time like this, bunch of people who believe safe programming is a language capability will jump out. But in fact, the most valuable part of the code in any nontrivial system is the “unsafe” yet safe ones. You write memory safe code by understanding how computers memory works, sometimes you can use certain patterns to make that process easier, but not always. This is regardless what language you use: you programming in Rust, still the most valuable part is where one can get the “unsafe” part right. A good C programmer will always a better Rust programmer when he wants to. That’s it.