You are relying on security through obscurity and ignoring Kerckhoff's Principle, as the security of your scheme comes solely from keeping the iteration count secret. However, when the iteration count is known/learned/guessed, the password is only protected by only three rounds of unsalted SHA256, which is extremely weak as it can be computed extremely quickly.
Three rounds is very easy to guess (there are crackers that already do this like mdxfind), but even if you used a larger iteration count, it could still be learned by reading the source, reverse engineering, etc. Especially in the case of web applications, many time the vector that was used to compromise the password database can also be leveraged to read other secrets on the system, such as the webapp source code, config files, etc. If we could rely on secrets being kept secret, then we wouldn't need password hashing in the first place. But we can't, so we do.
The example schemes I provided above do not hide their iteration count, as the security of the scheme does not depend on any obscurity. The security comes from thousands of iterations of salted SHA2. But again, SHA2 is easily accelerated so it is not really the best choice.
It is very clear that there is a lot of reading you need to do on the topic. There is a lot of information on this topic available on the Internet if you bother to search for it. In the meantime, please use a real password hashing function like those listed above, and do not attempt to create your own password hashing function. Look at some hashcat benchmarks and look at all of the algorithms that can be calculated millions or billions of times per second -- those are all people who designed their own password hashing functions and didn't have a clue what they are doing. Don't be one of those people.
Three rounds is very easy to guess (there are crackers that already do this like mdxfind), but even if you used a larger iteration count, it could still be learned by reading the source, reverse engineering, etc. Especially in the case of web applications, many time the vector that was used to compromise the password database can also be leveraged to read other secrets on the system, such as the webapp source code, config files, etc. If we could rely on secrets being kept secret, then we wouldn't need password hashing in the first place. But we can't, so we do.
The example schemes I provided above do not hide their iteration count, as the security of the scheme does not depend on any obscurity. The security comes from thousands of iterations of salted SHA2. But again, SHA2 is easily accelerated so it is not really the best choice.
It is very clear that there is a lot of reading you need to do on the topic. There is a lot of information on this topic available on the Internet if you bother to search for it. In the meantime, please use a real password hashing function like those listed above, and do not attempt to create your own password hashing function. Look at some hashcat benchmarks and look at all of the algorithms that can be calculated millions or billions of times per second -- those are all people who designed their own password hashing functions and didn't have a clue what they are doing. Don't be one of those people.