Any plans to change the settings storage to use NVS directly?

[TheCutter]

As stated EEPROM is deprecated:

EEPROM is deprecated. For new applications on ESP32, use Preferences. EEPROM is provided for backwards compatibility with existing Arduino applications. EEPROM is implemented using a single blob within NVS, so it is a container within a container. As such, it is not going to be a high performance storage method. Preferences will directly use nvs, and store each entry as a single object therein.

https://github.com/espressif/arduino-esp32/tree/master/libraries/EEPROM

[Gejakem]

In addition to @TheCutter , current method doesn't implement wear leveling.

[prampec]

Regarding wear: I don't think wear is a real problem, because I believe ESP32 uses flash memory instead of real EEPROM. Further more this library is not really meant for rapid rewrite of the configuration.

[Gejakem]

You're right to notice that detail. On the ESP32 there is no dedicated EEPROM hardware like on some AVR chips. IoTWebConf emulates EEPROM by using a section of the ESP32’s flash memory. So yes, where EEPROM is used in the library it will in fact use Flash.

About wear:
Both EEPROM and flash are non‑volatile memories that have limited write endurance. Typical flash cells on the ESP32 can handle around 10,000 to 100,000 write cycles per sector before wear becomes a concern.
EEPROM on microcontrollers usually has similar endurance characteristics, sometimes slightly higher.
So frequent writing to flash does carry the same wear risk as EEPROM. It’s not unique to EEPROM — the underlying physics of floating‑gate transistors applies to both.

I understand that in practice the Wifi-credentials will not change a lot (although while testing it will be much more frequently), but added parameters might change a lot (on every boot or maybe more frequent) depending on the application of course.

So, given the above I still think using something like <Preferences.h> will reduce the risk of Flash becoming corrupted substantially.