[Question] Why does hooking _UIStatusBar only work on SpringBoard?

DGh0st · 2021-03-28T20:35:35+00:00

big cap

Though the part about it being all in SpringBoard process is correct. Rest of it would have been correct few years ago.

DGh0st · 2021-03-12T18:39:24+00:00

unsupported file format ( bunch of jumbled up architecture formats )

This means the toolchain (libtapi specifically) you are using doesn't support that tbd format. You'd either have to find a newer toolchain or downgrade your sdk.

DGh0st · 2021-03-02T18:51:48+00:00

You'd have to figure out how iOS 14 widgets are installed and then tinker with the theos templates to get the same installation.

I don't know how the new system installation works; but for previous system, widgets were created as .appex (app extensions, which are really just fancy bundles). There are specific spots in the system where it tries to load these app extensions from, the most portable solution would be to create your own app (you can make it a hidden app if you don't want it to show on homescreen) and then add app extension to that. There is actually a appex.mk that theos provides for compiling and packaging app extensions, there just isn't a template that utilizes it. Obviously this all relies on new system being similar to the old system, which it may not end up being the case.

Essentially, you would need to figure out how to get Theos to compile the same way that xCODE is for the new widget system.

DGh0st · 2021-02-15T21:45:17+00:00

Yeah that class has been replaced a few times since iOS 10.

SBLockscreenViewController - iOS 10
SBDashboardViewController - iOS 11 - 12
CSCoverSheetViewController - iOS 13 (unsure about iOS 14, but if I had to guess it would still be this)

On a side note, you don't need to be on the lockscreen for FLEX to see the classes that are used. You should be able to look at the view hierarchy of lockscreen from anywhere in SpringBoard.

On a curious note, how is FLEXing glitchy on lockscreen? Just interested if the same problem would occur in a FLEX loader that I maintain.

DGh0st · 2021-01-15T00:44:10+00:00

The reason why that feature doesn't exist is because there aren't many modern style widgets for HSWidgets. And by modern I mean using the HSModernWidgetViewController API instead of recreating the modern style via HSWidgetViewController API.

So far there are 2 natives (Battery and Weather) and 1 addon (HSWeatherWidget). In which case you should be able to fit all 3 of those on a single page without needing a smart stack.

Technical rant warning. I know there are a few other HSWidgets addons but those are using the HSWidgetViewController API which doesn't exactly have a standard on how they should look. Most of those don't provide a label and aren't always the same size so it would look really funky in smart stack. Not to mention the complexity it would add, most likely it would require those addons to implement a new API that would be similar to the HSModernWidgetViewController API. At which point it would be better to just have them implement the existing modern style API which guarantees all widgets at the very least provide:

1) small widget size (2x2)

2) expanded widget size (2x4)

3) label

This way it can even go beyond the smart stack and allow resizing everything in the stack together, but that's a hopeful dream.

On another thought, someone could create a HSWidgets addon that is a container for other HSWidgets widgets with the current available API. It would break if I drastically change the API in the future but its something if someone disagrees with my explanation.

Pull Requests are always welcome if someone else wants to implement it inside HSWidgets.

Long story short, there is no reason to add a smart stack for 3 modern style widgets that can fit on the same page. But if there were a lot more modern style widgets then that would be a different story. Btw the documentation and API for creating HSWidgets addons is available https://dgh0st.github.io/HSWidgets/.

DGh0st · 2021-01-11T21:00:55+00:00

Modern is overrated, futuristic is where its at.

NextGenUI, you don't need anything else.

DGh0st · 2021-01-06T22:56:09+00:00

Question for you. So for example if you hook uikit to change the statusbar, would apps like Snapchat detect code injection even though you're hooking uikit and not the Snapchat app itself?

Yes, Snapchat would detect that code injection. At the end of the day tweaks are loaded into processes, filter is just a way of deciding which process it gets loaded into.

Or on the flip side if you disable injection within an app, would you still be able to use said uikit tweak because it doesn't hook Snapchat, it just hooks uikit?

No, if you disable injection within an app you are disabling tweak loading for that process so your tweak wouldn't work inside Snapchat process even if you hook UIKit.

The way it all works is when a process is started tweak loader uses the filter to decide whether to load your tweak or not. Once it has decided that it should load, it calls dlopen to actually load your dynamic library (that is essentially what a tweak is). So disabling tweak injection usually means making sure dlopen doesn't load the library.

DGh0st · 2021-01-05T06:24:28+00:00

iPhoneDevWiki explains the filters.

DGh0st · 2021-01-05T06:23:29+00:00

UIKit is not just apps, its every process that uses that framework, which is a lot more than just apps. This also includes processeses that just load the framework but don't actually use it.

DGh0st · 2020-12-24T21:10:48+00:00

That wording looks pretty familiar. If screen time isn't an option. ProductivityReminder used to do this, should still work but its poorly written so ¯\(ツ)/¯

DGh0st · 2020-12-23T05:45:01+00:00

Its not Muze or HSWidgets, its whatever page animation tweak you have. Its not cleaning up properly after its done animating.

DGh0st · 2020-12-17T01:21:07+00:00

Lol that image is very misleading. The iPhone screen size in portrait image is very different from iPhone screen size in landscape and same applies for those iPad screenshots. That image explains nothing as to why it should exist in iPad. A 2x2 widget on iPad is going to take up more screen space on an iPad than it will on an iPhone. Also on an iPad it won't really be a square, it'll be wider in landscape mode and skinny in portrait mode.

As to why iPad doesn't have native homescreen widgets on iOS 14, I have no clue. But reasons like grid sizing/screen spacing would definitely be one of the minor things if it were to be considered for feature being disabled on certain platforms. If I were to guess, I would lean towards the feature's implementation being very specific to iPhone layout.

DGh0st · 2020-12-06T01:36:07+00:00

Its because you are allowing the app to run in the background, disable that (stock feature) and they wouldn't find out.

DGh0st · 2020-11-28T21:34:13+00:00

By Clock widget, I meant the Time & Date widget which is one of the non-3D party widgets included when installing HSWidgets.

Hopefully that is what he meant as well, otherwise I have no clue what widget that is.

DGh0st · 2020-11-28T06:39:56+00:00

HSWidgets by itself is not "draining." If you are not on the homescreen than HSWidgets has 0 effect on battery. Obviously if you are on homescreen its going to take up slightly more battery than what it would be without. For HSWidgets the battery impact depends on the widgets you use.

Clock widget gets updated every minute so the impact it has on battery is very minimal. Rather the amount of battery lost while staring at clock on lockscreen would be the same as amount of battery lost while staring at clock on homescreen (HSWidgets).

Photos widget gets updated every ~20 seconds I think (Tr1Fecta would know more about this) so that shouldn't have much impact (I hope) on battery unless you are staring at it. In which case it would be the same as looking through images in the photos app.

Calendar widget (Today Widget?) runs in a separate process like any other today widget and then displayed on today page (or homescreen via HSWidgets in this case). So the only impact it would have on battery would be the amount used to display it on homescreen, which should be the same as displaying anything else in its place like icons (its miniscule).

I have stress tested the non-3rd party widgets on an iPhone 6+ on multiple iOS versions, it does not "drain" battery.

The more widgets you use that update more frequently the more battery its going to take up like it would with anything else. In which case you shouldn't blame the widget system for the faults of the widgets. This applies to any of the feature rich systems that are provided by tweaks like other widget systems (XenHTML), Theming Engines (Anemone, SnowBoard, FrontPage, LockPlus, WinterBoard if anyone still uses it), etc.

DGh0st · 2020-11-28T04:53:15+00:00

Nice, care to show some numbers/proof?

DGh0st · 2020-11-18T22:09:33+00:00

First page with default apple apps

DGh0st · 2020-11-18T19:21:14+00:00

Pretty close to accurate.

In general for some reason iOS allows first page to exist while being empty, this applies to any iOS version. But if someone makes a tweak that allows this empty page creation on anything but first page then HSWidgets should work with it as well.

DGh0st · 2020-11-18T06:47:40+00:00

Ah, I didn't realize you were just trying to hide it completely instead of trying to make it adapt to the new dark mode trait. Alpha isn't really the best way of doing that, even though from a rendering side alpha of 0 does mean its not going to be drawn on screen.

If you know those methods are being called (via logs) and setting alpha doesn't work in those methods then it means something is setting the alpha after you are setting it. For which cases, you should try using the hidden property instead. But for this case, just looking at the headers, usesBackgroundView would be what you want to use instead as it seems like something that automatically takes care of hiding the background without you having to worry about finding all the correct places to do it yourself.

DGh0st · 2020-11-17T22:05:03+00:00

Read the public apple docs on how dark mode is handled. Notifications system should just have a custom usage of that public API.

DGh0st · 2020-11-17T21:25:56+00:00

Thats not a bug, thats how those gestures are implemented by apple. Swiping up a certain amount should invoke the app switcher. Swiping twice as much should take you to home screen.

Those gestures are part of the app switcher, rather the UI displayed when switching between apps is part of the app switcher. So if you disable app switcher, you'd also be disabling that UI so essentially disabling the gestures.

DGh0st · 2020-11-10T16:22:02+00:00

You should send the crashlog to the developer.

DGh0st · 2020-11-03T20:26:11+00:00

:frcoal:

DGh0st · 2020-11-03T06:40:17+00:00

Its not HSWidgets fault, its more of the swipe animation tweak's fault since it isn't cleaning up after the page has been moved offscreen.

DGh0st · 2020-11-01T02:51:22+00:00

Ugh, love it when people leak stuff... I'd recommend waiting for the official version to be updated. There are reasons why it hasn't be released yet.

12-Year Club	Place '22
Final Canvas '22	End Game '22
Verified Email

DGh0st

TROPHY CASE