Can I encrypt a message by swapping bits in the text? I have tried out an encryption method, in which I swap bits in the text.
The text length is N bit, then I generate several random number pairs in the range 0..N-1, as [n,k] pairs. After that, I swap the n-th and k-th bits in the message, if they are different, of course. After several swaps the message becomes unreadable.
The message can be decrypted by applying the swaps in the reverse order.
Can this be a good encryption method or is it equivalent to the usual XOR cipher, or even weaker?
For example, I can generate the random number pairs with a pseudo-random number generator, with a starting seed. And the seed can be obtained from a passphrase, for example, an integer hash of the passphrase. Then I can use the passphrase to encrypt the message this way, and the same passphrase for decrypting, as the random number pairs will be the same again, due to the same seed applied at the start.
First problem is you're not specifying at all how many swaps you need to do for a given message length, other than saying it's "several." For an $n$-bit messsage there are $n!$ ways of rearranging its bits, gives a lower bound of $\mathrm{log}_2(n!) = \sum_{i=1}^{n}\mathrm{log}_2(i)$ bits for on how much pseudorandomness you'll need. Rather than analyze a precise number of rounds your random swaps method needs to achieve a good result, however, it's just simpler to substitute in a Fisher-Yates shuffle that'll fairly permute an $n$-item sequence in $n$ steps.

But whatever you do, even if we assume true random bit permutations, the technical answer is that this is straightforwardly insecure because an adversary can easily and reliably distinguish encryptions from random strings by looking whether the number of ones vs. zeroes is the same as their chosen plaintexts. A special case of this is that any message that's only zeroes or only ones encrypts to itself.

Even if we assume the attacker doesn't get to choose plaintexts, they can use this property to test whether a given ciphertext could be the encryption of some plaintext they guess at.  Take for example the binary ASCII codes for these strings:

HAHA ===&gt; 01001000 01000001 01001000 01000001 ===&gt;  8 ones
YEAH ===&gt; 01011001 01000101 01000001 01001000 ===&gt; 11 ones
NOPE ===&gt; 01001110 01001111 01010000 01000101 ===&gt; 14 ones


If I see a ciphertext with 11 ones I can tell that it's definitely neither HAHA nor NOPE, but could still be YEAH.