paperplane

joined 2 years ago
[–] [email protected] 0 points 1 day ago

To be fair, even with 3G networks being decommissioned, many countries still have 2G networks up and running to support older phones. Data speeds are usually way to slow to be useable, but for text messages it might work.

[–] [email protected] 0 points 1 day ago

By the way, it looks like someone already did this (though for iOS 6): https://chatgptlegacy.com/

The app seems to be open-source too: https://github.com/bag-xml/ChatGPT-for-Legacy-iOS

[–] [email protected] 0 points 1 day ago (1 children)

Don't think it would be impossible to make an app for both iOS 3 and 26. You wouldn't be able to make it binary-compatible due to different architectures, but you might be able to use the same source code to target both OSes. You'd have to use a very old Xcode version to target iOS 3, since deployment targets this old generally aren't really supported by recent Xcode versions, and you wouldn't be able to submit that version to the App Store. Naturally you'd have to limit yourself to some subset of UIKit APIs supported back then (that hasn't been deprecated and removed). But if done right, you should be able to open up the project with a recent Xcode, hit build and run it on iOS 26.

[–] [email protected] 3 points 2 weeks ago* (last edited 2 weeks ago)

Arguably mapping out cities to this degree across the globe is a ginormous effort, on an order of magnitude more so than what Google Maps etc. currently provide. Thus I don't think it's entirely unreasonable to try designing something that operates purely in terms of sensory input (and of course map data where available, those approaches don't have to be mutually exclusive).

[–] [email protected] 0 points 1 year ago

Projects for Apple platforms usually also use .h, where it could mean anything from C/C++ to Objective-C/C++.

In practice, Clang handles mixed C/C++/Obj-C codebases pretty well and determining the language for a header never really felt like an issue since the API would usually already imply it (declaring a C++ class and/or Obj-C class would require the corresponding language to consume it).

If a C++ header is intended to be consumed from C, adding the usual #ifdef __cplusplus extern "C" {... should alleviate the name mangling issues.