It is ok to include the iteration count in the resulting hash.
Most important, this allows you to increase the number of iterations when future hardware will become faster. It is necessary to be able to adapt to faster hardware, without loosing older hash values.
It wouldn't help much to hide this number. If it is not known, an attacker would assume a reasonable number, maybe a bit higher. He could not only compare the last iteration with the hash-value, but also every step between. In case of BCrypt with a logarithmic cost parameter, this would be about 3-5 compare operations more (too small numbers are not reasonable), that's not a big deal.
Well known APIs like PHP's password_hash() will include the cost parameter as well.
Edit: Hiding the number of iterations would add a kind of secret to the hashing process, an attacker has to guess this number. There are much better possibilities though to add a server side secret, i tried to explain this in my tutorial about safely storing passwords (have a look at the part about pepper and encrypting the hash-value).