Migration guide in Readme. Should everyone migrate to OSLog?

[lolgear]

New Issue Checklist

• I have read and understood the CONTRIBUTING guide
• I have read the Documentation or CocoaDocs
• I have searched for a similar issue in the project and found none

Issue Info

Info	Value
Platform Name	e.g. ios / osx / tvos / watchos
Platform Version	e.g. 8.0
CocoaLumberjack Version	e.g. 2.3.0
Integration Method	e.g. carthage / cocoapods / manually
Xcode Version	e.g. Xcode 7.3
Repro rate	e.g. all the time (100%) / sometimes x% / only once
Demo project link	e.g. link to a demo project that highlights the issue

Issue Description and Steps

This project was very good for many years, it was de-facto a standard framework for logging in iOS (and Apple ecosystem?).
But time goes by and, well, we should, at least, add migration guide to Readme.
First section should be "Why" this framework exists and "When" you can use it.
And only after these questions we can said:
If you still want to use this framework, well, that is how you can install it.

[ffried]

Well, OSLog is nice until you need to actually do something with the logs. Ever tried to attach them to a support request created by the user inside an app? Or export them, when the user writes to your hotline and says something is not working?

Since iOS 15 (and we have a lot of users that still need to support OS' before that), it's at least possible to retrieve log entries. But not the whole archive. Apple itself recommends having an existing log infrastructure set up:
https://developer.apple.com/forums/thread/677068?answerId=684250022#684250022

Furthermore, OSLog doesn't persist logs below a certain level. And there's no way for an app to dynamically enable it. You need to install a configuration profile that does so - you can imagine the amount of work necessary to explain this to users that don't have at least some technical knowledge.

OSLog is all sweet and nice if you just need to log some messages to show up in Xcode. Also, it works reasonably well (except for the dynamic level changing) on macOS, where you could access the log store since 10.15 (https://developer.apple.com/forums/thread/650843?answerId=668567022#668567022).

But it's still some big steps away from being a replacement for a proper logging infrastructure. Also, it doesn't work on Linux. So if your writing Swift packages, that run on both Darwin and Linux platforms, you won't be using OSLog (directly) - or you'll write lots of #if os(Linux) LinuxLog #else OSLog #endif.
swift-log solves this nicely by decoupling the frontend (log message creation) from the backend (log message writing / persisting). But even though they have some kind of multiplexing backend, it really works best with a single backend. And this is still a nice place for CocoaLumberjack to exist. Because multiplexing to various loggers is what it does best - on Darwin platforms. That way you can create multi-platform packages without needing the know the logging-backend. You just write your log messages. If your package ends up in an app, it'll for example use CocoaLumberjack as backend. If your package ends up on Linux, you use whatever log backend exists there, for example the one that comes with Vapor.

---

Long story short: It's a long way from being able to fully replace CocoaLumberjack with OSLog, since there's a lot that OSLog can't (and likely won't) do: remote logging, custom log formatting, structured logging, ...

[ffried]

Btw. since OSLog (at the moment) can't really be wrapped - due to it's static evaluation of message templates - it's not something the OpenSource community can solve.

[Howard-Flipped]

I'm looking for the right logging framework. Indeed, as the author says, many functions such as remote logging and other functions Apple certainly will not do, for the sake of so-called security. It has always been so, giving us less and less information. We can only develop the features we need ourselves.

[rogerluan]

Hi everyone 👋

Thanks for summarizing great points here about the pros/cons between CocoaLumberjack and OSLog. So if I understand it correctly, OSLog will work great if one abdicates of certain features that CocoaLumberjack offers, right?

Assuming that only "log to console" and "export logs so we can upload in a customer support ticket" is needed, sounds like one can successfully replace CocoaLumberjack with OSLog?

---

Resources:

• https://developer.apple.com/documentation/os/oslog
• https://developer.apple.com/forums/thread/705868
• https://swiftwithmajid.com/2022/04/19/exporting-data-from-unified-logging-system-in-swift/

[ffried]

Based on the platform, yea. On macOS, I don't see any issues. OSLogStore's API are all available and work as documented.

On iOS, the story is a bit different. Since iOS 15, it's possible to extract messages, but with limitations (mentioned in your forum link):

iOS has very limited facilities for reading the system log. Currently, an iOS app can only read entries created by that specific process, using .currentProcessIdentifier scope. This is annoying if, say, the app crashed and you want to know what it was doing before the crash. What you need is a way to get all log entries written by your app (r. 57880434).
There are two known bugs with the .currentProcessIdentifier scope. The first is that the .reverse option doesn’t work (r. 87622922). You always get log entries in forward order. The second is that the getEntries(with:at:matching:) method doesn’t honour its position argument (r. 87416514). You always get all available log entries.

Especially the first one can be a show-stopper when trying to debug crashes. The crash log might not be sufficient to track it down, but the logs are inaccessible.
The other two are not as bad IMHO - you just need to be aware of them. Though I do find them rather strange, making me wonder how weird the underlying implementation must be.

[rogerluan]

Yes, fair enough — those were great highlights. Thanks for this, @ffried ! 🙏

[rogerluan]

I wrote an article that summarizes all of my findings and learnings, as well as an alternative option if you'd really like to have OSLog during development, but can't give up on your advanced logging tools.

Check it out: https://www.roger.ml/p/oslog

I think this might help a lot of people as I couldn't find much information about this anywhere.

[xueyongwei]

Thank you,your article is very helpful to me, I tried a similar approach.

[rogerluan]

I'm glad the article was helpful @xueyongwei 🤗 thank you for the kind words!